Skip site navigation (1)Skip section navigation (2)

  
 
  

home | help
CREATE OPERATOR(7)	  PostgreSQL 18.6 Documentation       CREATE OPERATOR(7)

NAME
     CREATE_OPERATOR - define a new operator

SYNOPSIS
     CREATE OPERATOR name (
	 {FUNCTION|PROCEDURE} = function_name
	 [, LEFTARG = left_type ] [, RIGHTARG = right_type ]
	 [, COMMUTATOR = com_op ] [, NEGATOR = neg_op ]
	 [, RESTRICT = res_proc ] [, JOIN = join_proc ]
	 [, HASHES ] [, MERGES ]
     )

DESCRIPTION
     CREATE OPERATOR defines a new operator, name. The user who defines an oper-
     ator becomes its owner. If a schema name is given then the operator is cre-
     ated  in  the  specified  schema.	Otherwise  it  is created in the current
     schema.

     The operator name is a sequence of up  to	NAMEDATALEN-1  (63  by	default)
     characters from the following list:

	 + - * / < > = ~ ! @ # % ^ & | ` ?

     There are a few restrictions on your choice of name:

     *	 --  and  /* cannot appear anywhere in an operator name, since they will
	 be taken as the start of a comment.

     *	 A multicharacter operator name cannot end in + or -,  unless  the  name
	 also contains at least one of these characters:

	     ~ ! @ # % ^ & | ` ?

	 For  example,	@-  is an allowed operator name, but *- is not. This re-
	 striction allows PostgreSQL to parse SQL-compliant commands without re-
	 quiring spaces between tokens.

     *	 The symbol => is reserved by the SQL grammar, so it cannot be	used  as
	 an operator name.

     The  operator  !=	is  mapped to <> on input, so these two names are always
     equivalent.

     For binary operators, both LEFTARG and RIGHTARG must be defined. For prefix
     operators only RIGHTARG should be defined. The function_name function  must
     have  been  previously defined using CREATE FUNCTION and must be defined to
     accept the correct number of arguments (either one or two) of the indicated
     types.

     In the syntax of CREATE OPERATOR, the keywords FUNCTION and  PROCEDURE  are
     equivalent, but the referenced function must in any case be a function, not
     a procedure. The use of the keyword PROCEDURE here is historical and depre-
     cated.

     The  other clauses specify optional operator optimization attributes. Their
     meaning is detailed in Section 36.15.

     To be able to create an operator, you must have USAGE privilege on the  ar-
     gument  types  and the return type, as well as EXECUTE privilege on the un-
     derlying function. If a commutator or negator operator  is  specified,  you
     must own those operators.

PARAMETERS
     name
	 The name of the operator to be defined. See above for allowable charac-
	 ters.	The  name  can	be schema-qualified, for example CREATE OPERATOR
	 myschema.+ (...). If not, then the operator is created in  the  current
	 schema. Two operators in the same schema can have the same name if they
	 operate on different data types. This is called overloading.

     function_name
	 The function used to implement this operator.

     left_type
	 The data type of the operator's left operand, if any. This option would
	 be omitted for a prefix operator.

     right_type
	 The data type of the operator's right operand.

     com_op
	 The commutator of this operator.

     neg_op
	 The negator of this operator.

     res_proc
	 The restriction selectivity estimator function for this operator.

     join_proc
	 The join selectivity estimator function for this operator.

     HASHES
	 Indicates this operator can support a hash join.

     MERGES
	 Indicates this operator can support a merge join.

     To  give  a  schema-qualified operator name in com_op or the other optional
     arguments, use the OPERATOR() syntax, for example:

	 COMMUTATOR = OPERATOR(myschema.===) ,

NOTES
     Refer to Section 36.14 and Section 36.15 for further information.

     When you are defining a self-commutative operator, you just do it. When you
     are defining a pair of commutative operators, things are a little trickier:
     how can the first one to be defined refer	to  the  other	one,  which  you
     haven't defined yet? There are three solutions to this problem:

     *	 One way is to omit the COMMUTATOR clause in the first operator that you
	 define, and then provide one in the second operator's definition. Since
	 PostgreSQL knows that commutative operators come in pairs, when it sees
	 the  second  definition  it  will automatically go back and fill in the
	 missing COMMUTATOR clause in the first definition.

     *	 Another, more straightforward way is just to include COMMUTATOR clauses
	 in both definitions. When PostgreSQL processes the first definition and
	 realizes that COMMUTATOR refers to a nonexistent operator,  the  system
	 will  make  a dummy entry for that operator in the system catalog. This
	 dummy entry will have valid data only for the operator name,  left  and
	 right	operand  types,  and owner, since that's all that PostgreSQL can
	 deduce at this point. The first operator's catalog entry will	link  to
	 this  dummy entry. Later, when you define the second operator, the sys-
	 tem updates the dummy entry with the additional  information  from  the
	 second  definition.  If  you  try to use the dummy operator before it's
	 been filled in, you'll just get an error message.

     *	 Alternatively, both operators can be defined without COMMUTATOR clauses
	 and then ALTER OPERATOR can be used to set their commutator links. It's
	 sufficient to ALTER either one of the pair.

     In all three cases, you must own both operators in order to  mark	them  as
     commutators.

     Pairs  of	negator  operators  can be defined using the same methods as for
     commutator pairs.

     It is not possible to specify an operator's lexical  precedence  in  CREATE
     OPERATOR,	because the parser's precedence behavior is hard-wired. See Sec-
     tion 4.1.6 for precedence details.

     The obsolete options SORT1, SORT2, LTCMP, and GTCMP were formerly	used  to
     specify the names of sort operators associated with a merge-joinable opera-
     tor. This is no longer necessary, since information about associated opera-
     tors  is  found  by  looking at B-tree operator families instead. If one of
     these options is given, it is ignored except for implicitly setting  MERGES
     true.

     Use DROP OPERATOR to delete user-defined operators from a database. Use AL-
     TER OPERATOR to modify operators in a database.

EXAMPLES
     The  following  command defines a new operator, area-equality, for the data
     type box:

	 CREATE OPERATOR === (
	     LEFTARG = box,
	     RIGHTARG = box,
	     FUNCTION = area_equal_function,
	     COMMUTATOR = ===,
	     NEGATOR = !==,
	     RESTRICT = area_restriction_function,
	     JOIN = area_join_function,
	     HASHES, MERGES
	 );

COMPATIBILITY
     CREATE OPERATOR is a PostgreSQL extension.  There	are  no  provisions  for
     user-defined operators in the SQL standard.

SEE ALSO
     ALTER  OPERATOR  (ALTER_OPERATOR(7)),  CREATE OPERATOR CLASS (CREATE_OPERA-
     TOR_CLASS(7)), DROP OPERATOR (DROP_OPERATOR(7))

PostgreSQL 18.6 		      2026		      CREATE OPERATOR(7)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=CREATE_OPERATOR&sektion=7&manpath=FreeBSD+Ports+15.1.quarterly>

home | help