Re: invalid search_path complaints - Mailing list pgsql-hackers

From Tom Lane
Subject Re: invalid search_path complaints
Date
Msg-id 28647.1333558029@sss.pgh.pa.us
Whole thread Raw
In response to Re: invalid search_path complaints  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: invalid search_path complaints
Re: invalid search_path complaints
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You're getting squishy on me ...

> My feeling on this is that it's OK to warn if the search_path is set
> to something that's not valid, and it might also be OK to not warn.
> Right now we emit a NOTICE and I don't feel terribly upset about that;
> even if I did, I don't know that it's really worth breaking backward
> compatibility for.

> The WARNING on login is more troubling to me, because it's
> misdirected.  The warning is the result either of a setting that was
> never valid in the first place, or of a setting that became invalid
> when a schema was renamed or dropped.  The people responsible for the
> breakage are not necessarily the same people being warned; the people
> being warned may not even have power to fix the problem.

Well, we don't have any ability to nag "the people responsible",
assuming that those really are different people.  The real question to
me is whether we should produce no warning whatsoever despite the fact
that the setting is failing to operate as intended.  That's not
particularly cool either IMO.  I answered a question in pgsql-novice
just a couple hours ago that I think demonstrates very well the problems
with failing to issue any message about something not doing what it
could be expected to:
http://archives.postgresql.org/pgsql-novice/2012-04/msg00008.php

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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: poll: CHECK TRIGGER?
Next
From: Andrew Dunstan
Date:
Subject: Re: log chunking broken with large queries under load