- Software and digital services
- Databases
42883
PostgreSQL 42883 undefined_function: no matching routine call
Evidence linked to this decision
View source: PostgreSQL 18 Appendix A: Error CodesRisk level
Low
Usually safe to check without specialist tools.
Urgency
Medium
Quick answer
PostgreSQL returns SQLSTATE 42883 (undefined_function) when no function or operator in pg_proc matches both the requested name and the input argument types. Check the argument types with pg_typeof and verify search_path before adding an explicit CAST.
Safety first
Stop and check this first
- Never place functions in schemas where untrusted users hold CREATE privilege or call them without exact argument types or the VARIADIC keyword; Section 10.3 warns that a malicious user can create an overload and execute arbitrary SQL functions as though you executed them.
- Do not attempt to create ad-hoc wrapper functions or implicit casts in production to mask 42883, because extra overloads in pg_proc can make existing calls fail with ambiguous function errors.
Safe checks you can perform
- Inspect the exact argument data types with pg_typeof and the Position field
- Check routine existence and schema visibility using to_regproc and to_regprocedure
- Check whether the call targets a variadic function or defaulted parameters
Leave these tasks to a qualified professional
- Do not attempt this professional task: Cast ambiguous arguments explicitly and schema-qualify the function call
- Do not attempt this professional task: Deploy the missing function migration or trusted extension in the target database
What a technician must be able to justify
Technician visit
These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.
These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.
Cast ambiguous arguments explicitly and schema-qualify the function call
What they doHave the developer add explicit CAST(expr AS type) specifications on arguments that lack implicit casts, include the VARIADIC keyword when passing an array to a variadic function, and schema-qualify routines outside the default search path.
They must show youthe query with explicit CAST and schema qualification executing cleanly and returning the expected result type.
In writingthe exact function signature matched in pg_proc and the code diff adding the explicit CAST or schema prefix.
Deploy the missing function migration or trusted extension in the target database
What they doIf to_regprocedure confirmed the routine is absent from the connected database, have the DBA verify database backups and run the reviewed migration or CREATE EXTENSION script in the intended schema owned by a trusted role.
They must show youthe non-null OID and signature returned by to_regprocedure and pg_get_function_identity_arguments after deployment.
In writingthe schema name, owning role, routine identity arguments, and migration script applied.
Before accepting a part or repair
Nothing has been shown yet. Do not accept a part swap based on the code alone.
Follow these steps
Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.
Inspect the exact argument data types with pg_typeof and the Position field
- Who:
- You or your developer diagnosing the failing SQL call in a read-only session.
- How:
- Locate the routine or operator at protocol field P (Position) and test each argument expression with SELECT pg_typeof(<expr>) to see the actual data type inferred by PostgreSQL.
- Result that matters:
- The regtype name returned by pg_typeof for every argument passed to the function or operator.
- If pg_typeof shows an argument is integer, numeric, or another type that lacks an implicit cast to the documented parameter type, that confirms a type-conversion mismatch caused 42883.
- If every argument type already matches the expected signature exactly, that rules out an argument-type mismatch and points to search_path visibility or a missing routine.
- Evidence to keep:
- Record the output of pg_typeof for each argument and the exact function signature reported in the error message.
Evidence: PostgreSQL error and notice fields · PostgreSQL 18 system information functions · PostgreSQL 18 function type resolution
Check routine existence and schema visibility using to_regproc and to_regprocedure
- Who:
- Your developer or DBA querying system information functions without modifying any schema objects.
- How:
- Run SELECT current_schemas(true), to_regproc('schema_name.func_name'), to_regprocedure('schema_name.func_name(arg_types)') in the connected database.
- Result that matters:
- Whether the routine OID resolves when schema-qualified versus when searched across current_schemas(true).
- If to_regprocedure returns a valid OID when schema-qualified but fails without the schema prefix, that confirms the function exists in the database and is simply hidden by search_path.
- If both to_regproc and to_regprocedure return NULL even with the target schema name, that confirms no function with that name and signature exists in the current database.
- Evidence to keep:
- Keep the output of current_schemas(true), to_regproc, and to_regprocedure from the target database.
Never add schemas that permit untrusted users to create objects into search_path; qualify the routine name or keep functions in trusted schemas.
Evidence: PostgreSQL 18 system information functions · PostgreSQL 18 schemas
Check whether the call targets a variadic function or defaulted parameters
- Who:
- Your developer or DBA inspecting the function definition with pg_get_function_arguments.
- How:
- For any candidate OID found in pg_proc, run SELECT pg_get_function_arguments(oid), pg_get_function_identity_arguments(oid) to inspect VARIADIC arrays and default parameter positions.
- Result that matters:
- Whether the routine expects the VARIADIC keyword for an array argument or specific non-defaulted parameter types.
- If the function declares a VARIADIC array parameter and the caller passes an existing array without the VARIADIC keyword, that confirms why the array argument failed to match element expansion.
- If the parameter list matches only when explicit casts are supplied for unknown literals, that isolates the problem to untyped literal resolution in Section 10.3.
- Evidence to keep:
- Save the output of pg_get_function_arguments and pg_get_function_identity_arguments for the candidate routine.
Evidence: PostgreSQL 18 system information functions · PostgreSQL 18 function type resolution
Still not solved
If the error persists, stop here. See what the technician must do and show you.
Virtual technician
Does 42883 still appear after these checks?
This guided flow uses the exact code and your answers to choose a test, an expected result and the next branch.
Where this code applies
A code is meaningful only inside the right product and version context.
Primary scope
- System
- Software and digital services
- Brand
- PostgreSQL
- Product type
- Databases
Known code variants
- PostgreSQL 42883
- SQLSTATE 42883
- undefined_function
What it means
Appendix A assigns 42883 to undefined_function in Class 42, Syntax Error or Access Rule Violation. To resolve a function or operator call, PostgreSQL selects candidates from the pg_proc system catalog that match the name and argument count in the specified schema or current search_path, checks for an exact argument-type match, and filters candidates reachable via implicit conversions. If zero candidates survive, or if multiple candidates remain tied, resolution fails. This code alone does not prove the routine or extension is missing, because passing an integer where text is required or omitting a schema from search_path triggers the same error.
Warnings and stop conditions
- Highsource verified
Never place functions in schemas where untrusted users hold CREATE privilege or call them without exact argument types or the VARIADIC keyword; Section 10.3 warns that a malicious user can create an overload and execute arbitrary SQL functions as though you executed them.
Evidence: PostgreSQL 18 function type resolution · PostgreSQL 18 schemas
- Lowsource verified
Do not attempt to create ad-hoc wrapper functions or implicit casts in production to mask 42883, because extra overloads in pg_proc can make existing calls fail with ambiguous function errors.
Evidence: PostgreSQL 18 function type resolution
Symptoms and causes
Probable causes · in order
- Input argument data types have no implicit conversion to the function signatureCommon
PostgreSQL discards candidate functions whose parameter types do not match the supplied arguments and cannot be reached by an implicit cast, such as calling substr(1234, 3) with an integer instead of text.
Evidence: PostgreSQL 18 function type resolution
- Target function or operator lives in a schema outside the current search_pathCommon
For non-schema-qualified calls, PostgreSQL only considers functions in pg_proc that are visible in the current search_path, so a routine created in a separate application or extension schema is ignored.
Evidence: PostgreSQL 18 function type resolution · PostgreSQL 18 schemas
- Routine name is misspelled, argument count differs, or extension is not installedPossible
The pg_proc catalog in the connected database has no routine with that name and number of arguments because the migration or extension defining it has not been deployed to this database.
Evidence: PostgreSQL 18 system information functions · PostgreSQL 18 function type resolution
- Untyped literals or mixed argument categories leave no single best candidatePossible
When unknown-type literals or mixed argument types cannot be narrowed to a single candidate under the Section 10.3 best-match rules, PostgreSQL cannot deduce which function to call and fails.
Evidence: PostgreSQL 18 function type resolution
Sources and technical references
- 1
PostgreSQL 18 Appendix A: Error Codes
PostgreSQL Global Development Group · 2026 · official_doc
- 2
PostgreSQL error and notice fields
PostgreSQL Global Development Group · 2026 · official_doc
Was this entry useful?