DROP_PROCEDURE(7pg17)

💅 DROP_PROCEDURE — bestie, let's yeet a procedure

okay so real talk: this is DROP PROCEDURE from the PostgreSQL 17 manual (page 7, section 7 of the PostgreSQL 17.11 docs), and it does exactly what it says on the tin — it removes a procedure. icon behavior honestly.

---

✨ SYNOPSIS ✨

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

like, that's the whole vibe. IF EXISTS, a name, maybe some args in parens, maybe a comma and another one, and then CASCADE or RESTRICT to close it out. periodt. 🎀

---

🌸 DESCRIPTION 🌸

DROP PROCEDURE removes the definition of one or more existing procedures. literally just deletes them from existence, no cap.

To run this command you must be the owner of the procedure(s) — like, it's their procedure, you can't just walk in and drop it, that's not the vibe. 🙈

And the argument types to the procedure(s) usually must be specified, because several different procedures can totally exist with the same name but different argument lists. so you gotta be specific about which one you mean, iykyk.

---

💖 PARAMETERS 💖

• IF EXISTS — Do not throw an error if the procedure does not exist. a notice is issued in this case instead. so it's like, chill about it. ✨
• name — The name (optionally schema-qualified) of an existing procedure. yes bestie, schema-qualify it, you know you want to. 🦋
• argmode — The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN (but see below 👀).
• argname — The name of an argument. Note that DROP PROCEDURE does not actually pay any attention to argument names, since only the argument data types are used to determine the procedure's identity. so like... it's giving decoration. cute but functionally irrelevant. 💀
• argtype — The data type(s) of the procedure's arguments (optionally schema-qualified), if any. See below for details. this one actually matters, queen.
• CASCADE — Automatically drop objects that depend on the procedure, and in turn all objects that depend on those objects (see Section 5.15). domino effect, main character energy. 🔥
• RESTRICT — Refuse to drop the procedure if any objects depend on it. This is the default. so by default it's protective, not reckless. 🫶

---

⭐ NOTES ⭐

okay this is where it gets juicy, pay attention:

If there is only one procedure of the given name, the argument list can be omitted. and omit the parentheses too in this case — like DROP PROCEDURE do_db_maintenance; with no parens at all. slay.

In PostgreSQL, it's sufficient to list the input (including INOUT) arguments, because no two routines of the same name are allowed to share the same input-argument list. so like, the input list is already a unique fingerprint. 🔑

Moreover, the DROP command will not actually check that you wrote the types of OUT arguments correctly — so any arguments that are explicitly marked OUT are just noise. 🙈 but writing them is recommendable for consistency with the corresponding CREATE command. so do it anyway for the aesthetic.

For compatibility with the SQL standard, it's also allowed to write all the argument data types (including those of OUT arguments) without any argmode markers. When this is done, the types of the procedure's OUT argument(s) will be verified against the command. ✨

⚠️ okay but here's the plot twist: this provision creates an ambiguity, in that when the argument list contains no argmode markers, it's unclear which rule is intended. 😭 The DROP command will attempt the lookup both ways, and will throw an error if two different procedures are found. To avoid the risk of such ambiguity, it's recommendable to write IN markers explicitly rather than letting them be defaulted, thus forcing the traditional PostgreSQL interpretation to be used. ngl, just write the IN. save yourself the drama. 💅

The lookup rules just explained are also used by other commands that act on existing procedures, such as ALTER PROCEDURE and COMMENT ON PROCEDURE. so this whole thing applies over there too — consistency icon.

---

🎀 EXAMPLES 🎀

If there is only one procedure do_db_maintenance, this command is sufficient to drop it:

DROP PROCEDURE do_db_maintenance;

Given this procedure definition:

CREATE PROCEDURE do_db_maintenance(IN target_schema text, OUT results text) ...

any one of these commands would work to drop it:

DROP PROCEDURE do_db_maintenance(IN target_schema text, OUT results text);
DROP PROCEDURE do_db_maintenance(IN text, OUT text);
DROP PROCEDURE do_db_maintenance(IN text);
DROP PROCEDURE do_db_maintenance(text);
DROP PROCEDURE do_db_maintenance(text, text);  -- potentially ambiguous

However — and this is the important bit — the last example would be ambiguous if there is also, say:

CREATE PROCEDURE do_db_maintenance(IN target_schema text, IN options text) ...

see?? that's the whole argmode-marker situation from the notes showing up in real life. write your INs, bestie. 😭💖

---

🦋 COMPATIBILITY 🦋

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

• The standard only allows one procedure to be dropped per command.
• The IF EXISTS option is an extension.
• The ability to specify argument modes and names is an extension, and the lookup rules differ when modes are given.

so like, we're standard-compliant but with ✨ extra perks ✨.

---

🌈 SEE ALSO 🌈

• CREATE PROCEDURE (CREATE_PROCEDURE(7))
• ALTER PROCEDURE (ALTER_PROCEDURE(7))
• DROP FUNCTION (DROP_FUNCTION(7))
• DROP ROUTINE (DROP_ROUTINE(7))

the whole friend group honestly 🫶

---

and that's the page!! 💜 this one's straight from the PostgreSQL 17.11 Documentation, dated 2026, manual page DROP PROCEDURE(7) — go forth and drop responsibly, bestie. mwah. 💋✨