pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
pgsql: Avoid assertion failure if a setop leaf query contains setops.
6+ messages / 1 participants
[nested] [flat]

* pgsql: Avoid assertion failure if a setop leaf query contains setops.
@ 2024-11-20 17:04 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-11-20 17:04 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Avoid assertion failure if a setop leaf query contains setops.

Ordinarily transformSetOperationTree will collect all UNION/
INTERSECT/EXCEPT steps into the setOperations tree of the topmost
Query, so that leaf queries do not contain any setOperations.
However, it cannot thus flatten a subquery that also contains
WITH, ORDER BY, FOR UPDATE, or LIMIT.  I (tgl) forgot that in
commit 07b4c48b6 and wrote an assertion in rule deparsing that
a leaf's setOperations would always be empty.

If it were nonempty then we would want to parenthesize the subquery
to ensure that the output represents the setop nesting correctly
(e.g. UNION below INTERSECT had better get parenthesized).  So
rather than just removing the faulty Assert, let's change it into
an additional case to check to decide whether to add parens.  We
don't expect that the additional case will ever fire, but it's
cheap insurance.

Man Zeng and Tom Lane

Discussion: https://postgr.es/m/tencent_7ABF9B1F23B0C77606FC5FE3@qq.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/94131cd53c1552efe85c3e8120356c22cd658163

Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: Avoid assertion failure if a setop leaf query contains setops.
@ 2024-11-20 17:04 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-11-20 17:04 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Avoid assertion failure if a setop leaf query contains setops.

Ordinarily transformSetOperationTree will collect all UNION/
INTERSECT/EXCEPT steps into the setOperations tree of the topmost
Query, so that leaf queries do not contain any setOperations.
However, it cannot thus flatten a subquery that also contains
WITH, ORDER BY, FOR UPDATE, or LIMIT.  I (tgl) forgot that in
commit 07b4c48b6 and wrote an assertion in rule deparsing that
a leaf's setOperations would always be empty.

If it were nonempty then we would want to parenthesize the subquery
to ensure that the output represents the setop nesting correctly
(e.g. UNION below INTERSECT had better get parenthesized).  So
rather than just removing the faulty Assert, let's change it into
an additional case to check to decide whether to add parens.  We
don't expect that the additional case will ever fire, but it's
cheap insurance.

Man Zeng and Tom Lane

Discussion: https://postgr.es/m/tencent_7ABF9B1F23B0C77606FC5FE3@qq.com

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/fea81aee83b50c514c4ba6789e22c22c028e3df2

Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: Avoid assertion failure if a setop leaf query contains setops.
@ 2024-11-20 17:04 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-11-20 17:04 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Avoid assertion failure if a setop leaf query contains setops.

Ordinarily transformSetOperationTree will collect all UNION/
INTERSECT/EXCEPT steps into the setOperations tree of the topmost
Query, so that leaf queries do not contain any setOperations.
However, it cannot thus flatten a subquery that also contains
WITH, ORDER BY, FOR UPDATE, or LIMIT.  I (tgl) forgot that in
commit 07b4c48b6 and wrote an assertion in rule deparsing that
a leaf's setOperations would always be empty.

If it were nonempty then we would want to parenthesize the subquery
to ensure that the output represents the setop nesting correctly
(e.g. UNION below INTERSECT had better get parenthesized).  So
rather than just removing the faulty Assert, let's change it into
an additional case to check to decide whether to add parens.  We
don't expect that the additional case will ever fire, but it's
cheap insurance.

Man Zeng and Tom Lane

Discussion: https://postgr.es/m/tencent_7ABF9B1F23B0C77606FC5FE3@qq.com

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/fe084039e482673c2d7fbd881f7ce918c2512d50

Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: Avoid assertion failure if a setop leaf query contains setops.
@ 2024-11-20 17:04 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-11-20 17:04 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Avoid assertion failure if a setop leaf query contains setops.

Ordinarily transformSetOperationTree will collect all UNION/
INTERSECT/EXCEPT steps into the setOperations tree of the topmost
Query, so that leaf queries do not contain any setOperations.
However, it cannot thus flatten a subquery that also contains
WITH, ORDER BY, FOR UPDATE, or LIMIT.  I (tgl) forgot that in
commit 07b4c48b6 and wrote an assertion in rule deparsing that
a leaf's setOperations would always be empty.

If it were nonempty then we would want to parenthesize the subquery
to ensure that the output represents the setop nesting correctly
(e.g. UNION below INTERSECT had better get parenthesized).  So
rather than just removing the faulty Assert, let's change it into
an additional case to check to decide whether to add parens.  We
don't expect that the additional case will ever fire, but it's
cheap insurance.

Man Zeng and Tom Lane

Discussion: https://postgr.es/m/tencent_7ABF9B1F23B0C77606FC5FE3@qq.com

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/9b9689e26cb66ded459e9453a74d6de057eead4c

Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: Avoid assertion failure if a setop leaf query contains setops.
@ 2024-11-20 17:04 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-11-20 17:04 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Avoid assertion failure if a setop leaf query contains setops.

Ordinarily transformSetOperationTree will collect all UNION/
INTERSECT/EXCEPT steps into the setOperations tree of the topmost
Query, so that leaf queries do not contain any setOperations.
However, it cannot thus flatten a subquery that also contains
WITH, ORDER BY, FOR UPDATE, or LIMIT.  I (tgl) forgot that in
commit 07b4c48b6 and wrote an assertion in rule deparsing that
a leaf's setOperations would always be empty.

If it were nonempty then we would want to parenthesize the subquery
to ensure that the output represents the setop nesting correctly
(e.g. UNION below INTERSECT had better get parenthesized).  So
rather than just removing the faulty Assert, let's change it into
an additional case to check to decide whether to add parens.  We
don't expect that the additional case will ever fire, but it's
cheap insurance.

Man Zeng and Tom Lane

Discussion: https://postgr.es/m/tencent_7ABF9B1F23B0C77606FC5FE3@qq.com

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/3eb26524ca35f03faa5560debce253d3c8db5624

Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: Avoid assertion failure if a setop leaf query contains setops.
@ 2024-11-20 17:04 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2024-11-20 17:04 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Avoid assertion failure if a setop leaf query contains setops.

Ordinarily transformSetOperationTree will collect all UNION/
INTERSECT/EXCEPT steps into the setOperations tree of the topmost
Query, so that leaf queries do not contain any setOperations.
However, it cannot thus flatten a subquery that also contains
WITH, ORDER BY, FOR UPDATE, or LIMIT.  I (tgl) forgot that in
commit 07b4c48b6 and wrote an assertion in rule deparsing that
a leaf's setOperations would always be empty.

If it were nonempty then we would want to parenthesize the subquery
to ensure that the output represents the setop nesting correctly
(e.g. UNION below INTERSECT had better get parenthesized).  So
rather than just removing the faulty Assert, let's change it into
an additional case to check to decide whether to add parens.  We
don't expect that the additional case will ever fire, but it's
cheap insurance.

Man Zeng and Tom Lane

Discussion: https://postgr.es/m/tencent_7ABF9B1F23B0C77606FC5FE3@qq.com

Branch
------
REL_13_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/630520c22fbb03a68c51e150352efcd20ecde728

Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2024-11-20 17:04 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-20 17:04 pgsql: Avoid assertion failure if a setop leaf query contains setops. Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 17:04 pgsql: Avoid assertion failure if a setop leaf query contains setops. Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 17:04 pgsql: Avoid assertion failure if a setop leaf query contains setops. Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 17:04 pgsql: Avoid assertion failure if a setop leaf query contains setops. Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 17:04 pgsql: Avoid assertion failure if a setop leaf query contains setops. Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 17:04 pgsql: Avoid assertion failure if a setop leaf query contains setops. 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