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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Maaz Syed Adeeb <maaz(dot)adeeb(at)gmail(dot)com>
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 17:42:32
Message-ID: 3959547.1784310152@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Maaz Syed Adeeb <maaz(dot)adeeb(at)gmail(dot)com> writes:
>> 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?

The other thing that was irking me was that it numbers all the test
cases. That doesn't add any value, and what it does do is push
authors of new test cases very hard towards "add at the end", whether
or not that's the most sensible place for them in the overall
organization of the test script.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Rachitskiy 2026-07-17 18:24:43 Re: BUG #19555: TRAP: failed Assert (ent->cmin == change->data.tuplecid.cmin) on logical replication
Previous 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)