mirror of
https://github.com/postgres/postgres.git
synced 2025-07-30 11:03:19 +03:00
Improve parser's and planner's handling of set-returning functions.
Teach the parser to reject misplaced set-returning functions during parse
analysis using p_expr_kind, in much the same way as we do for aggregates
and window functions (cf commit eaccfded9
). While this isn't complete
(it misses nesting-based restrictions), it's much better than the previous
error reporting for such cases, and it allows elimination of assorted
ad-hoc expression_returns_set() error checks. We could add nesting checks
later if it seems important to catch all cases at parse time.
There is one case the parser will now throw error for although previous
versions allowed it, which is SRFs in the tlist of an UPDATE. That never
behaved sensibly (since it's ill-defined which generated row should be
used to perform the update) and it's hard to see why it should not be
treated as an error. It's a release-note-worthy change though.
Also, add a new Query field hasTargetSRFs reporting whether there are
any SRFs in the targetlist (including GROUP BY/ORDER BY expressions).
The parser can now set that basically for free during parse analysis,
and we can use it in a number of places to avoid expression_returns_set
searches. (There will be more such checks soon.) In some places, this
allows decontorting the logic since it's no longer expensive to check for
SRFs in the tlist --- so I made the checks parallel to the handling of
hasAggs/hasWindowFuncs wherever it seemed appropriate.
catversion bump because adding a Query field changes stored rules.
Andres Freund and Tom Lane
Discussion: <24639.1473782855@sss.pgh.pa.us>
This commit is contained in:
@ -604,6 +604,10 @@ subquery_planner(PlannerGlobal *glob, Query *parse,
|
||||
preprocess_expression(root, (Node *) parse->targetList,
|
||||
EXPRKIND_TARGET);
|
||||
|
||||
/* Constant-folding might have removed all set-returning functions */
|
||||
if (parse->hasTargetSRFs)
|
||||
parse->hasTargetSRFs = expression_returns_set((Node *) parse->targetList);
|
||||
|
||||
newWithCheckOptions = NIL;
|
||||
foreach(l, parse->withCheckOptions)
|
||||
{
|
||||
@ -1702,16 +1706,14 @@ grouping_planner(PlannerInfo *root, bool inheritance_update,
|
||||
* Figure out whether there's a hard limit on the number of rows that
|
||||
* query_planner's result subplan needs to return. Even if we know a
|
||||
* hard limit overall, it doesn't apply if the query has any
|
||||
* grouping/aggregation operations. (XXX it also doesn't apply if the
|
||||
* tlist contains any SRFs; but checking for that here seems more
|
||||
* costly than it's worth, since root->limit_tuples is only used for
|
||||
* cost estimates, and only in a small number of cases.)
|
||||
* grouping/aggregation operations, or SRFs in the tlist.
|
||||
*/
|
||||
if (parse->groupClause ||
|
||||
parse->groupingSets ||
|
||||
parse->distinctClause ||
|
||||
parse->hasAggs ||
|
||||
parse->hasWindowFuncs ||
|
||||
parse->hasTargetSRFs ||
|
||||
root->hasHavingQual)
|
||||
root->limit_tuples = -1.0;
|
||||
else
|
||||
@ -1928,7 +1930,11 @@ grouping_planner(PlannerInfo *root, bool inheritance_update,
|
||||
* weird usage that it doesn't seem worth greatly complicating matters to
|
||||
* account for it.
|
||||
*/
|
||||
tlist_rows = tlist_returns_set_rows(tlist);
|
||||
if (parse->hasTargetSRFs)
|
||||
tlist_rows = tlist_returns_set_rows(tlist);
|
||||
else
|
||||
tlist_rows = 1;
|
||||
|
||||
if (tlist_rows > 1)
|
||||
{
|
||||
foreach(lc, current_rel->pathlist)
|
||||
@ -4995,7 +5001,8 @@ make_sort_input_target(PlannerInfo *root,
|
||||
* Check for SRF or volatile functions. Check the SRF case first
|
||||
* because we must know whether we have any postponed SRFs.
|
||||
*/
|
||||
if (expression_returns_set((Node *) expr))
|
||||
if (parse->hasTargetSRFs &&
|
||||
expression_returns_set((Node *) expr))
|
||||
{
|
||||
/* We'll decide below whether these are postponable */
|
||||
col_is_srf[i] = true;
|
||||
@ -5034,6 +5041,7 @@ make_sort_input_target(PlannerInfo *root,
|
||||
{
|
||||
/* For sortgroupref cols, just check if any contain SRFs */
|
||||
if (!have_srf_sortcols &&
|
||||
parse->hasTargetSRFs &&
|
||||
expression_returns_set((Node *) expr))
|
||||
have_srf_sortcols = true;
|
||||
}
|
||||
|
Reference in New Issue
Block a user