Re: pg_dump search path issue

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Elijah Zupancic <elijah(at)zupancic(dot)name>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_dump search path issue
Date: 2015-02-05 01:32:11
Message-ID: 18195.1423099931@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

Elijah Zupancic <elijah(at)zupancic(dot)name> writes:
> In the SQL dump, you will notice that the SET search_path = xxx values
> will often not include the public schema which holds the functions
> needed to properly recreate tables that depend on extensions.

All the cases I've seen of this involve user-defined functions that are
broken, often dangerously so. A function should not assume that it's
being called with any particular search_path; if it's intended for use in
a multi-schema database, good practice is to either explicitly qualify
names or use a SET clause to force the search_path to be what it expects.

> It seems like the code that generates the SET search_path should check
> to see if any of the objects it is dumping depend on functions that
> use the public schema.

If that didn't involve solving the halting problem, we might try to do
it. But for better or worse, functions in Postgres are mostly black boxes
so far as callers are concerned. It's not possible for pg_dump to know
that some function has an expectation of being invoked with a particular
search path.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Elijah Zupancic 2015-02-05 02:01:31 Re: pg_dump search path issue
Previous Message Elijah Zupancic 2015-02-05 00:08:07 pg_dump search path issue

Browse pgsql-general by date

  From Date Subject
Next Message Elijah Zupancic 2015-02-05 02:01:31 Re: pg_dump search path issue
Previous Message Elijah Zupancic 2015-02-05 00:08:07 pg_dump search path issue