]> granicus.if.org Git - postgresql/commit
Disallow pushing volatile quals past set-returning functions.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 27 Sep 2016 22:43:36 +0000 (18:43 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 27 Sep 2016 22:43:36 +0000 (18:43 -0400)
commit72daabc7a3e75788df862104b8f723513c2471ae
tree2643e02e8f94bf48f74921c23b3ab87412421752
parent0109ab27609c0d58c1eddc6b799077d0968083de
Disallow pushing volatile quals past set-returning functions.

Pushing an upper-level restriction clause into an unflattened
subquery-in-FROM is okay when the subquery contains no SRFs in its
targetlist, or when it does but the SRFs are unreferenced by the clause
*and the clause is not volatile*.  Otherwise, we're changing the number
of times the clause is evaluated, which is bad for volatile quals, and
possibly changing the result, since a volatile qual might succeed for some
SRF output rows and not others despite not referencing any of the changing
columns.  (Indeed, if the clause is something like "random() > 0.5", the
user is probably expecting exactly that behavior.)

We had most of these restrictions down, but not the one about the upper
clause not being volatile.  Fix that, and add a regression test to
illustrate the expected behavior.

Although this is definitely a bug, it doesn't seem like back-patch
material, since possibly some users don't realize that the broken
behavior is broken and are relying on what happens now.  Also, while
the added test is quite cheap in the wake of commit a4c35ea1c, it would
be much more expensive (or else messier) in older branches.

Per report from Tom van Tilburg.

Discussion: <CAP3PPDiucxYCNev52=YPVkrQAPVF1C5PFWnrQPT7iMzO1fiKFQ@mail.gmail.com>
src/backend/optimizer/path/allpaths.c
src/test/regress/expected/subselect.out
src/test/regress/sql/subselect.sql