Tom Lane wrote: > So I think that labeling textanycat/anytextcat as immutable was a > thinko, and we instead ought to label them volatile so that the planner > can inline them no matter what the behavior of the underlying text cast > is.
That feels backwards, having to label functions as more volatile than they really are, just to allow optimizations elsewhere. Marking textanycat as not immutable would forbid using it in expression indexes, too. > ... The planner will not inline a function if the > resulting expression would be more volatile than the function claims > itself to be, because sometimes the point of such a function is to > hide the expression's volatility. ... Could we inline the function anyway, if it came from an operator? Presumably if you want to hide an expresssion's volatility, you use an explicit function call - I can't imagine using an operator for that purpose. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
