Remove unnecessary check on set-returning functions in values_lists
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50188psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 04:17 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50188_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50188_1 && git checkout t50188_1Patchset v1 (message #1) is on t50188_1
Hi,
I would like to understand the pull_up_simple_values code a little bit more.
Pull-up of simple values was implemented in 2015 by commit f4abd02. In
the is_simple_values I see a check on the expression_returns_set() of
the RTE values list.
But since d43a619 in 2017 the check_srf_call_placement has reported an
ERROR in the case of set-returning function inside a VALUES expression.
Let's demonstrate:
SELECT * FROM (VALUES ((generate_series(1,1E2))));
ERROR: set-returning functions are not allowed in VALUES
LINE 1: SELECT * FROM (VALUES ((generate_series(1,1E2))));
I think, the expression_returns_set examination doesn't necessary and we
can replace it with an assertion, if needed (see attachment).
Am I wrong?
--
regards, Andrei Lepikhov
Andrei Lepikhov <lepihov@gmail.com> writes:
I think, the expression_returns_set examination doesn't necessary and we
can replace it with an assertion, if needed (see attachment).
I think you may be right that this test is not really necessary given
the upstream parser test, but nonetheless I'm not inclined to remove
it. The upstream test is very far away in code terms, and there are
nearby steps like SQL-function inlining that make it less than 100%
obvious that an expression that was SRF-free at parse time still is
when we get here. I also don't care for destroying the parallel that
the comment mentions to the checks done before pulling up a subquery.
I'm reminded of Weinberg’s Law:
If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would
destroy civilization.
Unless there's a demonstrable, nontrivial performance hit from
this check, I think we should leave it alone.
regards, tom lane