diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2024-09-11 11:41:47 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2024-09-11 11:41:47 -0400 |
| commit | 77761ee5dddc0518235a51c533893e81e5f375b9 (patch) | |
| tree | 8c8293ac4640cd9b5ecdaf02d17441083b60a7b7 /src | |
| parent | 280423300b361eb9deff5ea40d4b0e6fab00211b (diff) | |
| download | postgresql-77761ee5dddc0518235a51c533893e81e5f375b9.tar.gz postgresql-77761ee5dddc0518235a51c533893e81e5f375b9.zip | |
Remove incorrect Assert.
check_agglevels_and_constraints() asserted that if we find an
aggregate function in an EXPR_KIND_FROM_SUBSELECT expression, the
expression must be in a LATERAL subquery. Alexander Lakhin found a
case where that's not so: because of the odd scoping rules for NEW/OLD
within a rule, a reference to NEW/OLD could cause an aggregate to be
considered top-level even though it's in an unmarked sub-select.
The error message that would be thrown seems sufficiently on-point,
so just remove the Assert. (Hence, this is not a bug for production
builds.)
This Assert was added by me in commit eaccfded9 (9.3 era). It looks
like I put it in to cross-check that the new logic for detecting
misplaced aggregates (using agglevelsup) caught the same cases that a
previous check on p_lateral_active did. So there might have been some
related misbehavior before eaccfded9 ... but that's very ancient
history by now, so I didn't dig any deeper.
Per bug #18608 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/18608-48de0717508ee429@postgresql.org
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/parser/parse_agg.c | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c index 102accd0716..efa730c1676 100644 --- a/src/backend/parser/parse_agg.c +++ b/src/backend/parser/parse_agg.c @@ -381,8 +381,6 @@ check_agglevels_and_constraints(ParseState *pstate, Node *expr) break; case EXPR_KIND_FROM_SUBSELECT: - /* Should only be possible in a LATERAL subquery */ - Assert(pstate->p_lateral_active); /* * Aggregate/grouping scope rules make it worth being explicit |