From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christoph Berg <cb(at)df7cb(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: invalid search_path complaints |
Date: | 2012-04-10 21:20:08 |
Message-ID: | 27617.1334092808@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
search_path_no_check.patch | text/x-patch | 9.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-04-10 21:43:12 | Re: pg_tablespace_location() error message |
Previous Message | Merlin Moncure | 2012-04-10 21:04:09 | Re: [JDBC] Regarding GSoc Application |