On Jan 18, Tom Lane modulated: > Karl Czajkowski <karlcz@xxxxxxx> writes: > > Is there a correctness hazard with pretending our function is > > IMMUTABLE, even though we will change the underlying config parameter > > in the same connection? > > You could probably get away with that if you never ever use prepared > queries (beware that almost anything in plpgsql is a prepared query). > It's a trick that's likely to bite you eventually though. > That sounds unnerving. I think I need to play it safe. :-/ Does the plan cache disappear with each connection/backend process? Or is there also a risk of plans being shared between backends? Would it be invasive or a small hack to have something like "transaction-immutable" which can be precomputed during planning, like immutable, but then must discard those plans at the end of the transaction...? karl -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
