Re: CREATE INDEX with an expression in an INCLUDE column fails with XX000 "unrecognized node type" instead of 0A000 on master

From: Maaz Syed Adeeb <maaz(dot)adeeb(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, matthew(dot)ripley28(at)gmail(dot)com
Subject: Re: CREATE INDEX with an expression in an INCLUDE column fails with XX000 "unrecognized node type" instead of 0A000 on master
Date: 2026-07-17 16:32:10
Message-ID: CAG+FJqNpLQZ5uc321W8oC7M8VzGmuJQx6vCkzrxHzuYGOq6--w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> Thanks. index_including.sql embodies all sorts of anti-patterns
> for testing: use of very generic object names that could conflict
> with concurrent test scripts, constant dropping and re-creation
> of objects ensuring that the overhead per useful test is as high
> as possible, etc.

Thanks for pushing it. This one seems like another nice opportunity to
clean up testing anti-patterns. Apart from the two mentioned, are there any
other anti patterns here? And any previous attempts/discussions to make it
better? I'm happy to start a new thread to collect the things that can be
improved, not just for this test but for any others as well (if any), and
work incrementally on making the tests better. Let me know.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-07-17 17:20:23 Re: BUG #19553: Wrong results from nested LEFT JOINs over an empty subquery (regression since v16)
Previous Message Christophe Courtois 2026-07-17 15:27:45 Re: BUG #19548: Missing dependency between a graph edge and the related PK