Robert Haas <robertmh...@gmail.com> writes: > On Tue, Apr 10, 2012 at 9:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Well, the other thing we could do is tweak the rules for when to print a >> complaint. I notice that in check_temp_tablespaces we use the rule >> >> source == PGC_S_SESSION (ie, SET) -> error >> source == PGC_S_TEST (testing value for ALTER SET) -> notice >> else -> silently ignore bad name >> >> which seems like it could be applied to search_path without giving >> anyone grounds for complaint. I'm still in favor of the previous patch >> for HEAD, but maybe we could do this in 9.1.
> Would that amount to removing the WARNING that was added in 9.1? If > so, I think I could sign on to that proposal. It would remove the warning that occurs while applying ALTER ... SET values. Another case that would change behavior is PGC_S_CLIENT; I observe that 9.1 rejects bad settings there entirely: $ PGOPTIONS="--search_path=foo" psql psql: FATAL: invalid value for parameter "search_path": "foo" DETAIL: schema "foo" does not exist but this did not happen in 9.0 so that seems like an improvement too. I believe that the other possible source values all correspond to cases where check_search_path would be executed outside a transaction and so would not do the check in question anyway. I've not tried to prove that exhaustively though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers