PostgreSQL Tutorial
Data Types
Querying & Filtering Data
Managing Tables
Modifying Data
Conditionals
Control Flow
Transactions & Constraints
Working with JOINS & Schemas
Roles & Permissions
Working with Sets
Subquery & CTEs
User-defined Functions
Important In-Built Functions
PostgreSQL PL/pgSQL
Variables & Constants
Stored Procedures
Working with Triggers
Working with Views & Indexes
Errors & Exception Handling
In PostgreSQL 11 and later, support for stored procedures was introduced. Unlike functions, stored procedures can be used to perform transactions within their body, among other capabilities. If you need to remove a stored procedure, you can use the DROP PROCEDURE
command.
DROP PROCEDURE [IF EXISTS] procedure_name([argument_types]) [CASCADE | RESTRICT];
IF EXISTS
: An optional keyword to prevent an error if the procedure doesn't exist. If the procedure doesn't exist and you don't use this clause, an error will be raised.
procedure_name
: The name of the procedure you want to drop.
argument_types
: A comma-separated list of the data types of the procedure's arguments. This is necessary because PostgreSQL allows procedure overloading, meaning you can have multiple procedures with the same name but different argument lists.
CASCADE
: This option will automatically drop objects that depend on the procedure.
RESTRICT
: This is the default behavior. It prevents the procedure from being dropped if any objects depend on it.
Drop a Simple Procedure:
Let's say you have a procedure named update_records
that takes a single integer
argument:
DROP PROCEDURE update_records(integer);
Using IF EXISTS:
If you're unsure whether a procedure exists and want to avoid an error in case it doesn't:
DROP PROCEDURE IF EXISTS update_records(integer);
Procedure Overloading: As PostgreSQL allows procedure overloading, you must specify the argument types to uniquely identify which version of the procedure you intend to drop.
Dependencies: If other database objects depend on the procedure, you might need to use the CASCADE
option to automatically drop those objects as well. Be cautious when using CASCADE
to ensure you understand the implications and potential cascading deletions.
Permissions: Only the owner of the procedure or a superuser can drop a procedure.
Backup: It's a best practice to always backup your database before making significant changes, like dropping procedures.
By exercising caution and always double-checking the procedure name and its arguments, you can ensure that you're dropping the intended procedure without unintentionally affecting other parts of your database.
Removing stored procedures in PostgreSQL:
DROP FUNCTION
to remove a stored procedure.DROP FUNCTION your_procedure_name(argument_type1, argument_type2);
Dropping procedures with specific signatures in PostgreSQL:
DROP FUNCTION IF EXISTS your_procedure_name(argument_type1, argument_type2) CASCADE;
Handling dependencies when dropping procedures in PostgreSQL:
-- Drop dependent objects first DROP TRIGGER your_trigger_name ON your_table; -- Drop the procedure DROP FUNCTION your_procedure_name(argument_type1, argument_type2);
Using DROP PROCEDURE IF EXISTS in PostgreSQL:
DROP FUNCTION IF EXISTS your_procedure_name(argument_type1, argument_type2) CASCADE;
Cascading options with DROP PROCEDURE in PostgreSQL:
CASCADE
to automatically drop dependent objects.DROP FUNCTION your_procedure_name(argument_type1, argument_type2) CASCADE;
Dropping procedures with multiple schemas in PostgreSQL:
DROP FUNCTION schema_name.your_procedure_name(argument_type1, argument_type2);
Dropping built-in procedures in PostgreSQL:
CREATE OR REPLACE FUNCTION pg_catalog.your_builtin_function(argument_type1, argument_type2) RETURNS return_type LANGUAGE sql AS $$ -- Your implementation $$;
Recovering space after dropping procedures in PostgreSQL:
VACUUM
command.-- Full vacuum on the entire PostgreSQL instance VACUUM FULL; -- Analyze for statistics update ANALYZE;