]> granicus.if.org Git - postgresql/commit
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 8 Nov 2013 16:37:00 +0000 (11:37 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 8 Nov 2013 16:37:00 +0000 (11:37 -0500)
commit9548bee2b19bee71e565a0a0aedd4d38ccb10a91
treee2e3030968729345a086b58b7d8d185737ce8e41
parent3c24b08f9bdc191d9e389dbcd97dbfb4cdb546d4
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