On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Christoph Berg <c...@df7cb.de> writes: >> Re: Tom Lane 2012-04-04 <28647.1333558...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
