Re: invalid search_path complaints
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Christoph Berg <cb@df7cb.de>
Cc: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2012-04-10T21:20:08Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revise the API for GUC variable assign hooks.
- 2594cf0e8c04 9.1.0 cited
Attachments
- search_path_no_check.patch (text/x-patch) patch
Christoph Berg <cb@df7cb.de> writes: > Re: Tom Lane 2012-04-04 <28647.1333558029@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? regards, tom lane