Re: invalid search_path complaints
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Scott Mead <scottm@openscg.com>, pgsql-hackers@postgresql.org
Date: 2012-04-05T00:53:04Z
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
On Wed, Apr 4, 2012 at 12:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. > But as soon as you say "I want warnings in some cases", I think we have > a mess that nobody is ever going to be happy with, because there will > never be a clear and correct definition of which cases should get > warnings. I'm not sure I'm ready to sign on the dotted line with respect to every aspect of your argument here, but that definition seems OK to me. In practice it's likely that a lot of the NOTICEs we emit now will only be seen when restoring dumps, and certainly in that case it's just junk anyway. So I think this would be fine. > In any case, I think we might be converging on an agreement that the > setting should be *applied* if syntactically correct, whether or not > we are agreed about producing a NOTICE or WARNING for unknown schemas. > If I have not lost track, that is what happened before 9.1 but is not > what is happening now, and we should change it to fix that compatibility > break, independently of the question about messaging. Sounds that way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company