CREATE_OPERATOR(7pg18)

✨ CREATE OPERATOR — bestie, we're making a WHOLE new operator ✨

okay so this page is CREATE OPERATOR(7) from the PostgreSQL 18.6 docs, and it's literally about inventing your own operator symbol. main character energy fr. let's get into it 💅

---

🌸 NAME 🌸

CREATE_OPERATOR — define a new operator. that's it, that's the vibe 🎀

---

🦋 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 💖

So CREATE OPERATOR defines a new operator called name. Whoever defines the operator becomes its owner — congrats, it's yours now 👑. If you give a schema name, the operator gets created in that schema. If you don't, it lands in the current schema.

The operator name is a sequence of up to NAMEDATALEN-1 characters (63 by default) picked from this lil' menu right here:

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

But bestie, there are a few rules, no cap:

• -- and /* can't appear anywhere in an operator name, because the parser would be like "oh that's a comment starting" 😭
• A multicharacter operator name can't end in + or -, unless the name also contains at least one of these characters:

~ ! @ # % ^ & | ` ?

Like, @- is an allowed operator name, but *- is not. This restriction is what lets PostgreSQL parse SQL-compliant commands without needing spaces between tokens. iconic honestly.

• The symbol => is reserved by the SQL grammar, so you literally cannot use it as an operator name. sorry babe 💀

Also, the operator != is mapped to <> on input, so those two names are always equivalent. they're the same girl, different font 💅

For binary operators, both LEFTARG and RIGHTARG must be defined. For prefix operators, only RIGHTARG should be defined. And the function_name function has to already exist (made with CREATE FUNCTION, obviously) and must be set up 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 keyword PROCEDURE here is historical and deprecated — it's giving vintage, and not in a cute way 🙈

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

To be able to create an operator, you need USAGE privilege on the argument types and the return type, plus EXECUTE privilege on the underlying function. And if you specify a commutator or negator operator, you have to own those operators too. rules are rules, periodt.

---

🎀 PARAMETERS 🎀

• name — the name of the operator to be defined. See above for the allowable characters. It can be schema-qualified, like CREATE OPERATOR myschema.+ (...). If it's not, then the operator gets 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. multitasking queen ✨
• function_name — the function used to implement this operator.
• left_type — the data type of the operator's left operand, if any. You'd omit this one 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, like this:

COMMUTATOR = OPERATOR(myschema.===) ,

---

🌈 NOTES 🌈

Refer to Section 36.14 and Section 36.15 for further information.

When you're defining a self-commutative operator, you just do it. easy. no drama. But when you're defining a pair of commutative operators, things get a lil' trickier — how can the first one to be defined refer to the other one, which you haven't defined yet? bestie it's giving chicken-and-egg 😭 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. she remembers everything 💅
• 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 system 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. placeholder era, but make it catalog 📝
• 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 Section 4.1.6 for precedence details. no negotiating with the parser, she said what she said 💀

The obsolete options SORT1, SORT2, LTCMP, and GTCMP were formerly used to specify the names of sort operators associated with a merge-joinable operator. This is no longer necessary, since information about associated operators 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. so like, they're basically ghosts at this point 👻

Use DROP OPERATOR to delete user-defined operators from a database. Use ALTER 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
);

ate. no crumbs. 🔥

---

💜 COMPATIBILITY 💜

CREATE OPERATOR is a PostgreSQL extension. There are no provisions for user-defined operators in the SQL standard. we're built different, and that's on purpose 🫶

---

🌸 SEE ALSO 🌸

• ALTER OPERATOR (ALTER_OPERATOR(7))
• CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7))
• DROP OPERATOR (DROP_OPERATOR(7))

---

okay bestie that's the whole page, go forth and define your own operators responsibly 💖 this was CREATE OPERATOR(7), straight outta the PostgreSQL 18.6 documentation, dated 2026 — mwah, slay, see you in the next manpage ✨👑🎀