On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Scott Mead <scottm@openscg.com> writes:
>> On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Well, that's an interesting analogy. Are you arguing that we should
>>> always accept any syntactically-valid search_path setting, no matter
>>> whether the mentioned schemas exist? It wouldn't be hard to do that.
>
>> I think we should always accept a syntactically valid search_path.
>
> I could live with that.
>
>>> The fun stuff comes in when you try to say "I want a warning in these
>>> contexts but not those", because (a) the behavior you think you want
>>> turns out to be pretty squishy, and (b) it's not always clear from the
>>> implementation level what the context is.
>
>> ISTM that just issuing a warning whenever you set the search_path (no
>> matter which context) feels valid (and better than the above *nix
>> behavior). I would personally be opposed to seeing it on login however.
>
> 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.
I think that part of the issue here is that it feels to you, as a
developer, that the per-user and per-database settings are applied on
top of the default from postgresql.conf. But the user doesn't think
of it that way, I think. To them, they expect the per-user or
per-database setting to "be there from the beginning", even though
that might not really be possible from an implementation perspective.
So they don't think of it being "applied" at startup time, and the
warning seems like a random intrusion (aside from possibly being log
spam).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
