Remove unnecessary check on set-returning functions in values_lists
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
Attachments:
0001-Remove-unnecessary-check-on-set-returning-functions-.patchtext/plain; charset=UTF-8; name=0001-Remove-unnecessary-check-on-set-returning-functions-.patchDownload+5-4
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