pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Remove incorrect Assert. 7+ messages / 1 participants [nested] [flat]
* pgsql: Remove incorrect Assert. @ 2024-09-11 15:42 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-11 15:42 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/77761ee5dddc0518235a51c533893e81e5f375b9 Modified Files -------------- src/backend/parser/parse_agg.c | 2 -- 1 file changed, 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Remove incorrect Assert. @ 2024-09-11 15:42 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-11 15:42 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7f88e50b455d0db51847fbfe63e53802d4527f3a Modified Files -------------- src/backend/parser/parse_agg.c | 2 -- 1 file changed, 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Remove incorrect Assert. @ 2024-09-11 15:42 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-11 15:42 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f3336626d2e35d490fe26a8af0f993a32105a226 Modified Files -------------- src/backend/parser/parse_agg.c | 2 -- 1 file changed, 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Remove incorrect Assert. @ 2024-09-11 15:42 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-11 15:42 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/abed06fdc5b23ca2b11adac236d43b6328fcfae1 Modified Files -------------- src/backend/parser/parse_agg.c | 2 -- 1 file changed, 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Remove incorrect Assert. @ 2024-09-11 15:42 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-11 15:42 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/14bb709b27fe3a3befc5d91358a8a9177155c00a Modified Files -------------- src/backend/parser/parse_agg.c | 2 -- 1 file changed, 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Remove incorrect Assert. @ 2024-09-11 15:42 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-11 15:42 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2be0e863204e08ff00c2c94f1750965d25cebb9f Modified Files -------------- src/backend/parser/parse_agg.c | 2 -- 1 file changed, 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Remove incorrect Assert. @ 2024-09-11 15:42 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-11 15:42 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/78d0bd452c78b17a788d2f15dc4e28bd3d3159c0 Modified Files -------------- src/backend/parser/parse_agg.c | 2 -- 1 file changed, 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-09-11 15:42 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-09-11 15:42 pgsql: Remove incorrect Assert. Tom Lane <tgl@sss.pgh.pa.us> 2024-09-11 15:42 pgsql: Remove incorrect Assert. Tom Lane <tgl@sss.pgh.pa.us> 2024-09-11 15:42 pgsql: Remove incorrect Assert. Tom Lane <tgl@sss.pgh.pa.us> 2024-09-11 15:42 pgsql: Remove incorrect Assert. Tom Lane <tgl@sss.pgh.pa.us> 2024-09-11 15:42 pgsql: Remove incorrect Assert. Tom Lane <tgl@sss.pgh.pa.us> 2024-09-11 15:42 pgsql: Remove incorrect Assert. Tom Lane <tgl@sss.pgh.pa.us> 2024-09-11 15:42 pgsql: Remove incorrect Assert. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox