Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 77761ee

Browse files
committed
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 eaccfde (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 eaccfde ... 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
1 parent 2804233 commit 77761ee

File tree

1 file changed

+0
-2
lines changed

1 file changed

+0
-2
lines changed

src/backend/parser/parse_agg.c

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -381,8 +381,6 @@ check_agglevels_and_constraints(ParseState *pstate, Node *expr)
381381

382382
break;
383383
case EXPR_KIND_FROM_SUBSELECT:
384-
/* Should only be possible in a LATERAL subquery */
385-
Assert(pstate->p_lateral_active);
386384

387385
/*
388386
* Aggregate/grouping scope rules make it worth being explicit

0 commit comments

Comments
 (0)