Merlin Moncure-2 wrote
> Regardless, the point at hand is whether specific plan semantics down
> the chain can control whether or not volatile expressions should run.
> Clearly, at least to me, they should not.
I don't personally see any solid reason to reject the always evaluate CTEs
with volatile expressions option but at the same time am then curious that
if it keeps coming up and constitutes a POLA violation why it hasn't been
done (e.g., insufficient demand for the cost or are there technical
concerns). How severe is the POLA violation and are there compelling
use-cases for and/or against implementing this solution?
Put differently ideally this should be put either on the todo list or the
"we do not want" list and further inquiries can then go to building up
enough popular demand to convince someone to implement it. Maybe there
should be a "convince us" list? Not a todo yet but something still be
considered.
Keeping in mind that there are likely volatile queries relying on the
current optimization that would become non-optimized and possibly very
poorly performing. Since the "fix" for these would be a simple alter
function to make them stable the cost benefit seems worthwhile - since those
functions are probably mis-identified in the first place due to the use of
the default.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Bug-Function-with-side-effects-not-evaluated-in-CTE-tp5774792p5775125.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.