pg_dump search_path breaks generated columns with unqualified function calls

Resolved 💬 2 comments Opened Dec 23, 2025 by evoludigit Closed Dec 23, 2025

Summary

When restoring a PostgreSQL dump containing tables with generated columns that use unqualified function calls (e.g., unaccent()), the restore fails because pg_dump sets search_path = ''.

Environment

  • PostgreSQL 17.6
  • pg_dump/pg_restore from same version

Problem

Tables with generated columns like:

slug_name text GENERATED ALWAYS AS (slugify(name)) STORED

Where slugify() uses unaccent():

CREATE FUNCTION public.slugify(value text) RETURNS text AS $$
BEGIN
  RETURN trim(BOTH '-' FROM regexp_replace(lower(unaccent(value)), '[^a-z0-9]+', '-', 'gi'));
END;
$$ LANGUAGE plpgsql IMMUTABLE STRICT;

Fail during COPY/INSERT because the dump file contains:

SELECT pg_catalog.set_config('search_path', '', false);

This resets the search_path, making unaccent() unfindable (it's in public schema).

Error

ERROR:  function unaccent(text) does not exist
CONTEXT:  PL/pgSQL function public.slugify(text) line 3 at RETURN

Workaround

Edit the dump file to restore the search_path:

sed -i "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public', false);/" dump.sql

Long-term Fix Options

  1. Fully qualify function calls in generated column expressions: public.unaccent()
  2. Set search_path in function definition: SET search_path = public
  3. Use pg_restore with appropriate flags

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗