Incident brief
Function does not exist
A function was called with an argument type it doesn't accept. PostgreSQL's overload resolution found no match, rather than silently coercing to something close.
What lands in your log
ERROR: function length(integer) does not exist
In 10 seconds
- What triggers it
- Call a real function using an argument type it doesn't accept.
- Fix
- Cast the argument to a type the function actually accepts.
- Proof
- Reproduced on PostgreSQL 16.14 → Calling length() with an integer argument was rejected with SQLSTATE 42883 and a HINT about explicit casts. The session was unaffected afterward.
Fix
What to do right now
Application-level steps for this error.
- Cast the argument to a type the function actually accepts.
- Check the function's documented signature rather than assuming every type is interchangeable.
- Don't assume a cast like ::text is a universal fix, see the premium test for why the same cast can still fail on a different function.
SELECT length(123::text);For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Function lookup depends on name, argument types, and search_path. Inspect all three before adding casts or creating another overload.
Candidate overloads and identity arguments
Replace the function name from the error; compare identity args with the actual bound parameter types.
SELECT n.nspname AS schema_name, p.proname,
pg_get_function_identity_arguments(p.oid) AS identity_arguments,
pg_get_function_result(p.oid) AS result_type
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE p.proname = '<function_name>'
ORDER BY n.nspname, identity_arguments;Function search path
Confirm which schemas PostgreSQL searches for an unqualified function call.
SELECT current_schemas(true) AS function_search_path;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 16 Documentation, §10.1 Overview (Type Conversion)
Since PostgreSQL permits function overloading, the function name alone does not uniquely identify the function to be called; the parser must select the right function based on the data types of the supplied arguments.Read the full section on postgresql.org →
The mismatched function call
length() has no overload accepting integer. PostgreSQL's function resolution found no candidate, per the manual, and reported the exact call it couldn't match.Confirming the session still works
The failed call didn't affect the session, the next statement ran normally.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Call a real function using an argument type it doesn't accept.
- 2PostgreSQL's function overload resolution finds no candidate that matches.
- 3SQLSTATE 42883 is reported, naming the exact call signature it looked for, with a HINT about explicit casts.
One client: call a real function (length) with an argument type it doesn't accept.
-- No table needed: the failure is function-overload resolution against a plain literal.
SELECT 'no schema required' AS setup_note;SELECT length(123);SELECT 1 AS session_still_alive;What PostgreSQL actually returned
setup_note
--------------------
no schema required
(1 row)ERROR: function length(integer) does not exist
LINE 1: SELECT length(123);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts. session_still_alive
----------------------
1
(1 row)The HINT's suggested fix, add an explicit type cast, was tested directly against the same call.
Without this
Above: length(123) has no matching overload.
With this, tested
Below: length(123::text) casts the argument to a type length() actually accepts.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- Fix that looks universal but doesn't apply to every function: exact SQL, output, and verdict
- A manual-grounded production interpretation of the lab result
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Verification
- Last verified
- 2026-07-15 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.