Marti Raudsepp <ma...@juffo.org> writes: > Case #1 uses the normal textcat(text, text) operator by automatically > coercing 'x' as text. > However, case #2 uses the anytextcat(anynonarray, text), which is > marked as volatile thus acts as an optimization barrier.
Hmm ... since those operators were invented (in 8.3), we have adopted a policy that I/O functions are presumed to be no worse than stable: http://archives.postgresql.org/pgsql-committers/2010-07/msg00307.php ISTM that would justify relabeling anytextcat/textanycat as stable, which should fix this. > One way would be doing preprocess_expression() before > pull_up_subqueries() so function inlining happens earlier, but I can't > imagine what unintended consequences that might have. I'm pretty sure that would be a bad idea. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
