]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 8 Nov 2013 16:37:08 +0000 (11:37 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 8 Nov 2013 16:37:08 +0000 (11:37 -0500)
commitaf38d140c71c21eda422fedc838525525d155cac
treecea2c45ad3a8a00c553272346c966bfcc9af964e
parent8cfd4c6a17472d74814eb8f8d8995f6b2fd02ef7
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.

This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT.  That could result in unexpected behavior
due to multiple evaluations of a volatile function, as in a recent
complaint from Etienne Dube.  It's been questionable from the very
beginning whether these functions should look into subqueries (as noted in
their comments), and this case seems to provide proof that they should.

Because the new code only descends into SubLinks, not SubPlans or
InitPlans, the change only affects the planner's behavior during
prepjointree processing and not later on --- for example, you can still get
it to use a volatile function in an indexqual if you wrap the function in
(SELECT ...).  That's a historical behavior, for sure, but it's reasonable
given that the executor's evaluation rules for subplans don't depend on
whether there are volatile functions inside them.  In any case, we need to
constrain the behavioral change as narrowly as we can to make this
reasonable to back-patch.
src/backend/optimizer/util/clauses.c
src/test/regress/expected/subselect.out
src/test/regress/sql/subselect.sql