DROP_OPERATOR_FAMILY(7pg17)

💅 DROP_OPERATOR_FAMILY (7pg17) — the "bye-bye operator family" page

okay so bestie, this is the PostgreSQL 17.11 documentation page for DROP OPERATOR FAMILY, and it's genuinely one of the cleaner ones. Let's get into it 🫶

---

🌸 NAME 🌸

DROP_OPERATOR_FAMILY — remove an operator family. that's it. that's the whole vibe. it deletes an operator family. slay.

---

✨ SYNOPSIS ✨

DROP OPERATOR FAMILY [ IF EXISTS ] name USING index_method [ CASCADE | RESTRICT ]

look at her. so structured. so iconic. 👑

---

🎀 DESCRIPTION 🎀

so DROP OPERATOR FAMILY drops an existing operator family, fr fr. but here's the gatekeeping part: to execute this command you must be the owner of the operator family. no owner, no drop. them's the rules 💅

also important, and this is the part people miss: DROP OPERATOR FAMILY does include dropping any operator classes contained in the family — like, those come along for the ride. but it does not drop any of the operators or functions referenced by the family. so the family goes poof, but the operators and functions it pointed at are still chilling. good for them honestly.

and if there are any indexes depending on operator classes within the family? you'll need to specify CASCADE for the drop to actually complete. otherwise it's not happening. no cap.

---

🔥 PARAMETERS 🔥

• IF EXISTS — do not throw an error if the operator family does not exist. a notice is issued in this case instead. very "no thoughts, just a gentle heads up" of it 🦋
• name — the name (optionally schema-qualified) of an existing operator family. yup, you can schema-qualify it, go off.
• index_method — the name of the index access method the operator family is for. so like, which access method's world this family lives in.
• CASCADE — automatically drop objects that depend on the operator family, and in turn all objects that depend on those objects (see Section 5.15). it's a whole chain reaction, main character energy cascading down 🌊
• RESTRICT — refuse to drop the operator family if any objects depend on it. this is the default. so if you don't say anything, the answer is no. boundaries 💀

---

💖 EXAMPLES 💖

removing the B-tree operator family float_ops, as one does:

DROP OPERATOR FAMILY float_ops USING btree;

but bestie, read the fine print: this command will not succeed if there are any existing indexes that use operator classes within the family. add CASCADE to drop such indexes along with the operator family. it's giving "you can't just leave without cleaning up your room" 😭

---

🌈 COMPATIBILITY 🌈

there is no DROP OPERATOR FAMILY statement in the SQL standard. so this is a PostgreSQL-exclusive experience. iykyk 💜

---

🧚 SEE ALSO 🧚

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

the whole operator family cinematic universe fr fr 🌸

---

lowkey a heads up: RESTRICT is the default, so if it's refusing to drop and you're confused — that's why. check for dependent indexes first before you go reaching for CASCADE 👀

---

and that's the page! this was PostgreSQL 17.11 documentation, dated 2026, DROP OPERATOR FAMILY(7) — go forth and drop responsibly, bestie 💅✨🎀