Re: BUG #14649: Function Namespace Resolution Bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeremy Cowgar <jeremy(at)cowgar(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14649: Function Namespace Resolution Bug
Date: 2017-05-12 20:10:51
Message-ID: 9062.1494619851@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jeremy Cowgar <jeremy(at)cowgar(dot)com> writes:
> I didn’t realize that pg_dump alters the search path. Couldn’t pg_dump
> simply append the default search path to the end of it’s custom setting?

There's no particularly good reason to believe that there's a single
"default" search_path that would apply to all usages in a given database.
Even if there were, sticking another schema in front of it wouldn't
produce the same results, ie if you have code that fails when the
search_path isn't "f, g, h", it may well fail when the search_path is
"g, f, g, h", because schema g would win ambiguous references over
schema f.

We could maybe make this work if pg_dump never touched the search_path
at all, but that would be a quite subtle change creating its own set of
hazards.

The long and the short of it is that code in CHECK constraints (or
triggers) is well advised not to depend on any particular search_path;
blaming pg_dump for exposing that is just shooting the messenger.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message nilesoien 2017-05-12 21:27:23 BUG #14651: Uninitialized page fix corrupted TOAST table
Previous Message Jeremy Cowgar 2017-05-12 19:16:49 Re: BUG #14649: Function Namespace Resolution Bug