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
- Fully qualify function calls in generated column expressions:
public.unaccent() - Set
search_pathin function definition:SET search_path = public - Use
pg_restorewith appropriate flags
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗