DROP_FUNCTION(7pg14)

💅 DROP_FUNCTION 💅

okay so bestie, the manual name is DROP_FUNCTION and we're looking at the PostgreSQL 14.24 docs — let's get into it ✨

---

🎀 NAME 🎀

DROP_FUNCTION — remove a function, periodt. like literally just yeet that function out of existence 💀

---

✨ SYNOPSIS ✨

DROP FUNCTION [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

---

💖 DESCRIPTION 💖

okay so DROP FUNCTION removes the definition of an existing function. that's it, that's the vibe 🦋

but listen — to execute this command, the user must be the owner of the function. no cap, you can't just drop someone else's stuff 🙈

also the argument types to the function must be specified, since several different functions can exist with the same name and different argument lists. like yes bestie there can be multiple functions with the same name, it's giving main character energy for each overload ✨

---

🌸 PARAMETERS 🌸

• IF EXISTS — do not throw an error if the function does not exist. a notice is issued in this case. so it's like, chill, no drama if it's already gone 👑
• name — the name (optionally schema-qualified) of an existing function. if no argument list is specified, the name must be unique in its schema. iykyk 💅
• argmode — the mode of an argument: IN, OUT, INOUT, or VARIADIC. if omitted, the default is IN. note that DROP FUNCTION does not actually pay any attention to OUT arguments, since only the input arguments are needed to determine the function's identity. so it is sufficient to list the IN, INOUT, and VARIADIC arguments. basically OUT arguments are like, not invited to this party 🎀
• argname — the name of an argument. note that DROP FUNCTION does not actually pay any attention to argument names, since only the argument data types are needed to determine the function's identity. so yeah, names don't matter here, it's what's inside that counts 💖
• argtype — the data type(s) of the function's arguments (optionally schema-qualified), if any. this is the actual tea ☕
• CASCADE — automatically drop objects that depend on the function (such as operators or triggers), and in turn all objects that depend on those objects (see Section 5.14). it's giving domino effect, everything falls 🔥
• RESTRICT — refuse to drop the function if any objects depend on it. this is the default. so it's like, protective mode activated, won't let you break stuff by accident 🫶

---

🦋 EXAMPLES 🦋

this command removes the square root function:

DROP FUNCTION sqrt(integer);

drop multiple functions in one command, because why not slay multiple at once:

DROP FUNCTION sqrt(integer), sqrt(bigint);

if the function name is unique in its schema, it can be referred to without an argument list:

DROP FUNCTION update_employee_salaries;

note that this is different from

DROP FUNCTION update_employee_salaries();

which refers to a function with zero arguments, whereas the first variant can refer to a function with any number of arguments, including zero, as long as the name is unique. okay so the parentheses matter bestie, don't forget them or you're talking about a different function entirely 😭

---

🌈 COMPATIBILITY 🌈

this command conforms to the SQL standard, with these PostgreSQL extensions:

• the standard only allows one function to be dropped per command. postgres said "we can do better" 💅
• the IF EXISTS option
• the ability to specify argument modes and names

---

⭐ SEE ALSO ⭐

• CREATE FUNCTION (CREATE_FUNCTION(7))
• ALTER FUNCTION (ALTER_FUNCTION(7))
• DROP PROCEDURE (DROP_PROCEDURE(7))
• DROP ROUTINE (DROP_ROUTINE(7))

---

okay that's the whole vibe bestie, go drop those functions responsibly 💖✨🎀🦋🌸💅

this has been the PostgreSQL 14.24 documentation, dated 2026 — catch you on the flip side, mwah 🫶💜