How to fix Ambiguous function in PostgreSQL

PostgreSQLINTERMEDIATEMEDIUMUpdated Dec 27, 2025· 187 views

PostgreSQL throws an ambiguous function error when it cannot determine which overloaded function to call due to unclear argument types or multiple matching candidates. Resolve this by using explicit type casts or qualifying function calls.

Quick fix

Fixes Ambiguous function

-- Ambiguous call
SELECT generate_series($1, $2, $3);

-- Fixed with explicit casts
SELECT generate_series($1::integer, $2::integer, $3::integer);
  1. Add explicit type casts to function arguments
  2. Qualify the function with its schema name
  3. Check PostgreSQL function overloads with psql
  4. Rename variables to avoid PL/pgSQL ambiguity
postgresql — error
-- Ambiguous call
SELECT generate_series($1, $2, $3);
-- Fixed with explicit casts
SELECT generate_series($1::integer, $2::integer, $3::integer);
Ambiguous function

What this error means

PostgreSQL allows multiple functions with the same name but different parameter types (function overloading). When you call a function, PostgreSQL uses a resolution algorithm to determine which version to execute. If two or more function versions match your arguments equally well with no clear winner, PostgreSQL raises an "ambiguous function" error. This happens because the database cannot reliably choose between competing candidates without more information about which function you intended to call.

Typical symptoms

  • Query fails with "ERROR: function_name(...) is ambiguous" message
  • HINT suggests adding explicit type casts
  • Error occurs when calling overloaded functions with generic argument types (like unknown)
  • Works in one schema but fails after creating a similar function in another schema

Common causes

  1. Multiple function versions exist with identical parameter names but the argument types provided could match more than one version
  2. Function arguments have unknown or generic types that match multiple function signatures
  3. Functions with the same name exist in different schemas and search_path makes resolution ambiguous
  4. Default parameters create multiple matching candidates with identical non-default parameter types
  5. Type coercion rules allow more than one function to accept your argument types with equal precedence

How to fix "Ambiguous function"

1Add explicit type casts to function arguments

Explicitly cast ambiguous arguments to the exact types expected by the function. This tells PostgreSQL precisely which function version to call.

sql
-- Ambiguous call
SELECT generate_series($1, $2, $3);

-- Fixed with explicit casts
SELECT generate_series($1::integer, $2::integer, $3::integer);
2Qualify the function with its schema name

If functions with the same name exist in multiple schemas, prefix the function name with the schema name to remove ambiguity.

sql
-- Ambiguous
SELECT my_function(arg1, arg2);

-- Clear schema ownership
SELECT public.my_function(arg1, arg2);
-- or
SELECT custom_schema.my_function(arg1, arg2);
3Check PostgreSQL function overloads with psql

Use the \df command in psql to list all overloaded versions of a function and their exact signatures.

sql
-- List all versions of a function
\df function_name

-- More detailed output
\df+ function_name

Review the parameter types listed to understand which signature your call should match.

4Rename variables to avoid PL/pgSQL ambiguity

In PL/pgSQL functions, ambiguity can occur between variable names and column names. Use a naming convention like prefixing variables with v_.

sql
CREATE FUNCTION my_func() AS $$
DECLARE
  v_word text;  -- prefix variables
BEGIN
  SELECT id FROM emp a WHERE a.id = v_word;  -- qualify table references
END;
$$ LANGUAGE plpgsql;
5Review function parameter defaults

If multiple function versions have different sets of default parameters, PostgreSQL may not be able to distinguish them. Consider renaming functions or simplifying parameter sets.

sql
-- Problem: two versions with overlapping defaults
CREATE FUNCTION process(a int, b int DEFAULT 0) ...
CREATE FUNCTION process(a int, b int DEFAULT 1) ...  -- ambiguous!

-- Solution: use different function names
CREATE FUNCTION process_default(a int, b int DEFAULT 0) ...
CREATE FUNCTION process_custom(a int, b int) ...

Advanced notes

PostgreSQL uses a multi-step resolution algorithm for function overloading: it first checks for exact type matches, then preferred types within a category, then falls back to implicit type conversions. If multiple candidates remain after all steps, the error is raised. The search_path setting controls which schema is searched first; if you have identically-named functions in different schemas, ensure your search_path is ordered to prefer trusted schemas and prevent ambiguity. For C-language functions, overloaded variants must have different C function names internally. In PL/pgSQL, use the plpgsql.variable_conflict setting (values: error, use_variable, use_column) to control how ambiguous names are resolved between variables and columns.

Frequently asked questions

What does "Ambiguous function" mean?
PostgreSQL allows multiple functions with the same name but different parameter types (function overloading). When you call a function, PostgreSQL uses a resolution algorithm to determine which version to execute. If two or more function versions match your arguments equally well with no clear winner, PostgreSQL raises an "ambiguous function" error.
How do I fix "Ambiguous function"?
PostgreSQL throws an ambiguous function error when it cannot determine which overloaded function to call due to unclear argument types or multiple matching candidates. Resolve this by using explicit type casts or qualifying function calls.
What causes "Ambiguous function"?
Multiple function versions exist with identical parameter names but the argument types provided could match more than one version Function arguments have unknown or generic types that match multiple function signatures Functions with the same name exist in different schemas and search_path makes resolution ambiguous
Is the "Ambiguous function" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading