CREATE_OPERATOR_FAMILY(7pg14)

🌸 CREATE_OPERATOR_FAMILY(7pg14) — the glow-up era of operator families

okay bestie, so this is the CREATE_OPERATOR_FAMILY(7) page from the PostgreSQL 14.24 Documentation and it's genuinely so much less scary than the name makes it look. we're making an operator family. that's it. that's the vibe. let's get into it 💅

---

✨ NAME ✨

CREATE_OPERATOR_FAMILY — define a new operator family 🫶

🦋 SYNOPSIS 🦋

CREATE OPERATOR FAMILY name USING index_method

like, that's the whole thing. two things and you're done. iconic.

💖 DESCRIPTION 💖

okay so CREATE OPERATOR FAMILY creates a new operator family. and what is an operator family, you ask? it's a collection of related operator classes, plus maybe some extra operators and support functions that are compatible with those operator classes but not essential to how any individual index actually functions. it's giving friend group energy — the operator classes are the main characters, and the loose operators are the chill friends who show up and vibe 🎀

and here's the important bit, so listen up: operators and functions that are essential to indexes should be grouped within the relevant operator class, rather than being "loose" in the operator family. don't leave your essential faves out here unattended. typically, single-data-type operators are bound to operator classes, while cross-data-type operators can be loose in an operator family containing operator classes for both data types. iykyk 🌈

the new operator family is initially empty — like a fresh group chat with no messages yet. it should be populated by issuing subsequent CREATE OPERATOR CLASS commands to add contained operator classes, and optionally ALTER OPERATOR FAMILY commands to add "loose" operators and their corresponding support functions. build it up, bestie, one class at a time 💜

if a schema name is given then the operator family is created in the specified schema. otherwise it's created in the current schema. and no cap: two operator families in the same schema can have the same name only if they are for different index methods. same name, same schema, same index method? nope, not allowed, that's a collision and we don't do that 🙈

the user who defines an operator family becomes its owner. main character ownership energy, love that for you 👑

⚠️ okay so the serious bit, and i'm not gonna sugarcoat it: presently, the creating user must be a superuser. and the reason is lowkey intense — this restriction is made because an erroneous operator family definition could confuse or even crash the server. 💀 crash it. the whole server. so yeah, superuser only, no exceptions, please be careful.

refer to Section 38.16 for further information. more reading, more lore, go off 📚

🧚 PARAMETERS 🧚

• name — the name of the operator family to be created. it can be schema-qualified. yes queen, you can be specific about where it lives.
• index_method — the name of the index method this operator family is for. which friend group is this, basically ✨

🎀 COMPATIBILITY 🎀

CREATE OPERATOR FAMILY is a PostgreSQL extension. there is no CREATE OPERATOR FAMILY statement in the SQL standard. so if you go looking for it in the SQL standard like "where is she", she's not there. she's ours. periodt 💅

🔥 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))

the whole family (pun absolutely intended) — go read them all, you'll be so smart 🧠💖

---

and that's the whole page bestie!! 🌈 this absolute icon of a manpage comes to you courtesy of PostgreSQL 14.24, dated 2026, and honestly? she ate. now go forth and create responsibly (as a superuser, obviously) 🍓👑✨