Pavel Stehule <pavel.steh...@gmail.com> writes: > 2018-06-04 9:59 GMT+02:00 Vik Fearing <vik.fear...@2ndquadrant.com>: >> On 04/06/18 09:37, Pavel Stehule wrote: >>> Yes, it is incorrect mark. Unfortunately - this is often workaround for >>> wrong estimations - so I afraid, in this case, your proposed fix breaks >>> lot of applications.
>> I would say such applications are already broken. > I cannot to agree, not in this moment: > 1. there is not any workaround, how to force subselect evaluation in > planning time - what can be correct for once only evaluated queries. There's the sadly-underdocumented trick of writing the expression inside a sub-select so that it becomes an InitPlan. We could doubtless improve our support for that --- for instance, teach estimate_expression_value() how to get an estimated value when the expression is stable --- but I'm unconvinced that we need new infrastructure for this. Inventing a new function volatility class would be an enormous mess from users' standpoint, especially if the reason was only to distinguish cheating uses from non-cheating uses of the existing class. I am not inclined to promise that we'll never break cheating uses. regards, tom lane