DROP_FUNCTION(7pg17)

💅 DROP FUNCTION — the "bestie, delete this function" page (PostgreSQL 17.11 docs, DROP_FUNCTION(7))

okay so real talk, this one's a banger. let's get into it ✨

---

🌸 NAME

DROP_FUNCTION — remove a function. that's it. that's the whole vibe. yeet the function 🫶

---

🎀 SYNOPSIS

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

look at her. iconic. slightly terrifying. very demure syntax 🦋

---

💖 DESCRIPTION

DROP FUNCTION removes the definition of an existing function. poof. gone. no cap.

but here's the thing bestie: to actually execute this command, the user must be the owner of the function. not your friend, not your coworker, you. 👑

and the argument types to the function must be specified, because — and this is the plot twist — several different functions can totally exist with the same name and different argument lists. so like, the name alone isn't enough to tell them apart. it's giving "everyone named Emma in this class" energy. 😭

---

✨ PARAMETERS ✨

• IF EXISTS — do not throw an error if the function doesn't exist. a notice is issued in this case instead. so it's the polite version of "hey, she's not here" 🌈
• name — the name (optionally schema-qualified) of an existing function. if no argument list is specified, the name must be unique in its schema. no duplicates allowed, periodt.
• argmode — the mode of an argument: IN, OUT, INOUT, or VARIADIC. if omitted, the default is IN. quick note tho: 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. slay, less typing 💅
• argname — the name of an argument. and again: 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 don't stress about the names, they're just there being decorative 🎀
• argtype — the data type(s) of the function's arguments (optionally schema-qualified), if any. that's the part that actually matters fr fr
• 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.15). it's giving domino effect. be careful with this one 🔥
• RESTRICT — refuse to drop the function if any objects depend on it. this is the default. the safe, sensible, responsible queen 👑

⚠️ okay but seriously, CASCADE takes out everything that depends on the function, and then everything that depends on those things. read the dependencies before you go feral 😭

---

💜 EXAMPLES

this command removes the square root function:

DROP FUNCTION sqrt(integer);

drop multiple functions in one command — yes you can do that, we love efficiency:

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

now this one's cute 🍓 if the function name is unique in its schema, it can be referred to without an argument list:

DROP FUNCTION update_employee_salaries;

and note that this is different from

DROP FUNCTION update_employee_salaries();

the second one 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. yes. that's a whole different thing. no, it doesn't feel fair. it's just how it is 🙈

---

🌈 COMPATIBILITY

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

• The standard only allows one function to be dropped per command. we allow more. we're generous like that 💖
• 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))

the whole friend group honestly 🫶

---

and that's the page bestie ✨ brought to you by the PostgreSQL 17.11 documentation, dated 2026. go forth and drop responsibly, mwah 💋🎀