From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Fix incorrect tests for SRFs in relation_can_be_sorted_early(). |
Date: | 2022-08-03 21:33:53 |
Message-ID: | E1oJM01-000BHa-Bb@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
Commit fac1b470a thought we could check for set-returning functions
by testing only the top-level node in an expression tree. This is
wrong in itself, and to make matters worse it encouraged others
to make the same mistake, by exporting tlist.c's special-purpose
IS_SRF_CALL() as a widely-visible macro. I can't find any evidence
that anyone's taken the bait, but it was only a matter of time.
Use expression_returns_set() instead, and stuff the IS_SRF_CALL()
genie back in its bottle, this time with a warning label. I also
added a couple of cross-reference comments.
After a fair amount of fooling around, I've despaired of making
a robust test case that exposes the bug reliably, so no test case
here. (Note that the test case added by fac1b470a is itself
broken, in that it doesn't notice if you remove the code change.
The repro given by the bug submitter currently doesn't fail either
in v15 or HEAD, though I suspect that may indicate an unrelated bug.)
Per bug #17564 from Martijn van Oosterhout. Back-patch to v13,
as the faulty patch was.
Discussion: https://postgr.es/m/17564-c7472c2f90ef2da3@postgresql.org
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/1aa8dad41ffad99923a658389ee948e88394491c
Modified Files
--------------
src/backend/nodes/nodeFuncs.c | 6 ++++++
src/backend/optimizer/path/equivclass.c | 4 ++--
src/backend/optimizer/util/tlist.c | 11 +++++++++++
src/include/optimizer/optimizer.h | 5 -----
4 files changed, 19 insertions(+), 7 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-08-03 22:07:56 | Re: Unstable tests for recovery conflict handling |
Previous Message | Robert Haas | 2022-08-03 20:33:46 | Re: Unstable tests for recovery conflict handling |