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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
