PostgreSQL raises duplicate_function (code 42723) when you attempt to create a function whose name, argument types, and schema already match an existing function.
PostgreSQL duplicate_function (42723) happens when CREATE FUNCTION defines a signature that already exists in the same schema. Change the parameter list, drop or rename the old function, or qualify with a different schema to resolve the error.
PostgreSQL duplicate_function Error 42723
PostgreSQL throws duplicate_function when a new CREATE FUNCTION statement conflicts with an already defined function that shares the same name, argument data types, and schema. PostgreSQL treats that trio as a unique signature.
The error halts deployment scripts, migrations, and ad-hoc DDL because the server refuses to shadow an existing routine.
Fixing it quickly matters to keep CI pipelines green and avoid breaking API layers depending on deterministic function behavior.
Calling CREATE FUNCTION with a signature that already exists is the primary trigger.
PostgreSQL checks the current database catalog and raises error code 42723 before any new object is written.
Other triggers include restoring a dump that contains duplicate definitions, generating migration files twice, or running CREATE OR REPLACE FUNCTION but accidentally omitting OR REPLACE.
First, verify the conflicting signature with \df+ in psql or by querying pg_proc.
Drop the old function if it is no longer needed, or rename it to preserve historical logic.
When both versions must coexist, overload by changing argument types, adding DEFAULT values, or moving one version into a dedicated schema. Using CREATE OR REPLACE FUNCTION is the safest way to update code without dropping privileges or grants.
During migrations, rerunning the same script twice often produces duplicate_function.
Wrap statements in IF NOT EXISTS checks or use CREATE OR REPLACE to make scripts idempotent.
In CI pipelines, parallel jobs may deploy identical functions concurrently. Apply advisory locks or run migrations serially to avoid race conditions.
Adopt a strict naming convention that includes schema prefixes and version numbers. Store DDL in source control and gate merges with lint rules that detect duplicate signatures.
Galaxy’s SQL editor highlights existing objects in real time.
When you type CREATE FUNCTION, the autocomplete panel shows conflicting signatures so you can rename or alter the function before executing.
Error 42710 duplicate_object appears when you recreate tables or indexes with the same name. Error 42712 duplicate_alias occurs within query scopes. All follow the same prevention pattern: check existence, rename, or use IF NOT EXISTS.
.
The most common cause is an earlier CREATE FUNCTION with identical name and argument types already committed to the same schema.
Running the same migration twice, either manually or by mis-configured CI jobs, reproduces the same function signature and triggers duplicate_function.
Altering only the return type or VOLATILE/STABLE attribute keeps the signature unchanged, so PostgreSQL still sees a duplicate.
Restoring a database dump into an environment that already contains some of the functions doubles up the signature.
.
Yes, if the goal is to update the code while keeping the same signature. It will overwrite the existing body without raising error 42723.
Absolutely. PostgreSQL supports overloading based on argument types and count. Ensure each version has a unique signature.
Run \df in psql or query pg_catalog.pg_proc joined to pg_namespace to list all user-defined functions.
Parallel jobs may apply the same migration concurrently. Serialize migration steps or acquire advisory locks to prevent duplication.
.avif)
.avif){kind=logo}
