On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Scott Mead <sco...@openscg.com> writes: >> On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers