DROP_FUNCTION(7)

๐Ÿ’– DROP_FUNCTION ๐Ÿ’–

okay bestie, gather round, because today we're learning how to yeet a function out of existence ๐Ÿซถ

DROP_FUNCTION โ€” remove a function โœจ


โœจ SYNOPSIS โœจ

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

๐ŸŒธ DESCRIPTION ๐ŸŒธ

So like. DROP FUNCTION removes the definition of an existing function. That's it, that's the whole vibe. ๐Ÿ’…

But no cap, there are rules:

  • to run this command, you must be the owner of the function. not your cousin, not your group chat, you. ๐Ÿ‘‘
  • you gotta specify the argument types of the function, because lowkey several different functions can have the exact same name with different argument lists. it's giving "same name, different energy" โ€” so the arg types are how Postgres tells them apart. ๐Ÿ”ฅ

๐ŸŽ€ PARAMETERS ๐ŸŽ€

  • IF EXISTS โ€” don't throw an error if the function doesn't exist. instead a notice gets issued. so like, no dramatic meltdown, just a little "hmm, wasn't there anyway" note. ๐Ÿ™ˆ
  • name โ€” the name (optionally schema-qualified) of an existing function. if you don't give an argument list, then the name has to be unique in its schema. periodt.
  • argmode โ€” the mode of an argument: IN, OUT, INOUT, or VARIADIC. if you omit it, the default is IN. now here's the tea ๐Ÿต: 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's sufficient to list the IN, INOUT, and VARIADIC arguments. the OUT ones are just... there. main character energy but no lines. ๐Ÿ˜ญ
  • 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. names are decoration, bestie. cute but irrelevant. โœจ
  • argtype โ€” the data type(s) of the function's arguments (optionally schema-qualified), if any. the actual identity check. the real one. ๐Ÿ”
  • 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, it's giving chain reaction. ๐Ÿฆ‹
  • RESTRICT โ€” refuse to drop the function if any objects depend on it. this is the default. she's cautious, she's responsible, she said no. ๐Ÿ›‘

๐ŸŒˆ EXAMPLES ๐ŸŒˆ

this command removes the square root function:

DROP FUNCTION sqrt(integer);

drop multiple functions in one command โ€” multitasking queen ๐Ÿ’…:

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. yes bestie, those two lines are lowkey not the same thing. the parentheses are doing so much work. ๐Ÿ’€


โญ COMPATIBILITY โญ

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

  • the standard only allows one function to be dropped per command.
  • the IF EXISTS option
  • the ability to specify argument modes and names

so like, we're standard-compliant and we brought extras. overachiever behaviour. ๐ŸŽ€


๐Ÿฆ‹ SEE ALSO ๐Ÿฆ‹


and that's the whole page, bestie ๐Ÿ’– this one's from PostgreSQL 18.6, dated 2026, and it's literally called DROP FUNCTION(7). go forth and drop responsibly, mwah ๐Ÿซถโœจ