CREATE_OPERATOR_FAMILY(7pg17)

💖 CREATE_OPERATOR_FAMILY 💖

ok so bestie, this is the CREATE_OPERATOR_FAMILY page from the PostgreSQL 17.11 docs — yes, the 7pg17 one, you found it, you're doing amazing 🫶. Buckle up, we're making a whole operator family together and it's gonna be iconic.

---

✨ NAME ✨

CREATE_OPERATOR_FAMILY — literally just: define a new operator family. that's the whole vibe. 💅

---

🌸 SYNOPSIS 🌸

CREATE OPERATOR FAMILY name USING index_method

look at her. two parameters. clean. slay. ✨

---

🦋 DESCRIPTION 🦋

okay so CREATE OPERATOR FAMILY creates a shiny new operator family, no cap. and what even is an operator family, you ask? 🧚 it defines a collection of related operator classes — plus maybe some extra operators and support functions that are compatible with those operator classes but are not essential for the functioning of any individual index. iykyk.

💀 real talk though: operators and functions that are essential to indexes should be grouped inside the relevant operator class, NOT left hanging "loose" in the operator family. typically, single-data-type operators are bound to operator classes, while cross-data-type operators can be loose in an operator family that contains operator classes for both data types. noted. periodt.

so the new operator family starts out completely empty — it's giving blank canvas, main character energy. you populate it by issuing subsequent CREATE OPERATOR CLASS commands to add the contained operator classes, and optionally ALTER OPERATOR FAMILY commands to add those "loose" operators and their corresponding support functions. 🌈

now, the schema situation: if a schema name is given, the operator family gets created in that specified schema. otherwise it lands in the current schema. and here's the rule — two operator families in the same schema can have the same name only if they're for different index methods. that's the vibe check. 👑

and the user who defines an operator family becomes its owner. 🎀 currently, the creating user must be a superuser. why? because an erroneous operator family definition could confuse or even crash the server 😭 — yeah, that's the whole reason for the restriction, not just to gatekeep.

for further info, go refer to Section 36.16. it's giving required reading. 📚

---

🎀 PARAMETERS 🎀

• name — the name of the operator family you're creating. and yes, it can be schema-qualified. 💖
• index_method — the name of the index method that this operator family is for. that's it, that's the one. ✨

---

⭐ COMPATIBILITY ⭐

CREATE OPERATOR FAMILY is a PostgreSQL extension, bestie — a homegrown original. there is no CREATE OPERATOR FAMILY statement in the SQL standard. we're built different. 💅

---

🌟 SEE ALSO 🌟

• ALTER OPERATOR FAMILY (ALTER_OPERATOR_FAMILY(7))
• DROP OPERATOR FAMILY (DROP_OPERATOR_FAMILY(7))
• CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7))
• ALTER OPERATOR CLASS (ALTER_OPERATOR_CLASS(7))
• DROP OPERATOR CLASS (DROP_OPERATOR_CLASS(7))

---

and that's the whole page, bestie — go forth and create operator families responsibly 💜

sign-off szn: this was PostgreSQL 17.11, dated 2026, brought to you by the letters C, R, E, A, T, E and the number 7. mwah. 😘