> -----Original Message----- > There really needs to be some way to specify that when an expression is > evaluated for each row in a set, a function used within that expression is not > optimized away for some rows. Fortunately we have a way: > > http://www.postgresql.org/docs/9.2/interactive/sql-createfunction.html > > | VOLATILE indicates that the function value can change even within a > | single table scan, so no optimizations can be made. Relatively few > | database functions are volatile in this sense; some examples are > | random(), [...] > > The behavior in the OP's query would certainly be sane if the function were > not VOLATILE; as it is, I have a hard time seeing this as anything but a bug.
What are the arguments against adding a 4th identifier - call it PER_ROW for this argument? The main reason VOLATILE is broken is that it is the default and in order to minimize beginner's penalty it is not treated as such in some situations. The new one could behave just like VOLATILE but would never be optimized away and would always evaluate once for each row in its context. Then the question is whether you write a new "random()" function or break backwards compatibility and alter the existing version. David J. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
