On Jan 18, Tom Lane modulated: > "The same as IMMUTABLE" would be to reduce the function to a constant at > plan time, which would be the wrong thing. It would be valid to execute > it only once at query start, but there's no built-in mechanism for that. > That's what I was afraid of... right, we'd like for it to partially evaluate these and then finish the plan. Is there a correctness hazard with pretending our function is IMMUTABLE, even though we will change the underlying config parameter in the same connection? It would be very bad if we changed our parameter to reflect a different web client identity context, but then somehow got cached plans based on the previous setting... > But you could force it by putting it in a sub-SELECT, that is if you > don't like the performance of > > SELECT ... slow_stable_function() ... > > try this: > > SELECT ... (SELECT slow_stable_function()) ... > Ha, you might recall a while back I was having problems with round-tripping our RLS policies because I had tried such sub-selects which return arrays and the internal format lost the casts needed to get the correct parse when reloading a dump... :-) karl -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
