Re: invalid search_path complaints

On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Christoph Berg <cb(at)df7cb(dot)de> writes:
>> Re: Tom Lane 2012-04-04 <28647(dot)1333558029(at)sss(dot)pgh(dot)pa(dot)us>
>>> Now, Scott's comment seems to me to offer a principled way out of this:
>>> if we define the intended semantics of search_path as being similar
>>> to the traditional understanding of Unix PATH, then it's not an error
>>> or even unexpected to have references to nonexistent schemas in there.
>
>> Btw, the default setting does already work like this: "$user",public.
>> It is not an error for "$user" not to exist, but it is a very nice
>> default because it will be used as soon as it appears.
>
> Yeah.  Between that and the fact that there are a lot of cases where we
> simply fail to check path validity at all (eg, if it's coming from
> postgresql.conf), I'm becoming more and more convinced that just
> removing the existence check is the best thing.
>
> Attached is a proposed patch for this.  (Note: the docs delta includes
> mention of permissions behavior, which was previously undocumented but
> has not actually changed.)
>
> I am not sure whether we should consider back-patching this into 9.1,
> although that would be necessary if we wanted to fix Robert's original
> complaint against 9.1.  Thoughts?

I guess my feeling would be "no", because it seems like a clear
behavior change, even though I agree the new behavior's better. Since
my original investigation was prompted by a customer complaint, it's
tempting to say we should, but there's not much good making customer A
happy if we make customer B unhappy with the same change.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company