Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wkma6-000s7l-3A for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Jul 2026 17:42:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wkma4-001PG4-2K for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Jul 2026 17:42:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wkma4-001PFw-1W for pgsql-bugs@lists.postgresql.org; Fri, 17 Jul 2026 17:42:36 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wkma1-00000000hwU-2TJn for pgsql-bugs@lists.postgresql.org; Fri, 17 Jul 2026 17:42:35 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 66HHgWHs3959548; Fri, 17 Jul 2026 13:42:32 -0400 From: Tom Lane To: Maaz Syed Adeeb cc: pgsql-bugs@lists.postgresql.org, matthew.ripley28@gmail.com Subject: Re: CREATE INDEX with an expression in an INCLUDE column fails with XX000 "unrecognized node type" instead of 0A000 on master In-reply-to: References: <3574719.1784140144@sss.pgh.pa.us> <3577449.1784142765@sss.pgh.pa.us> <3789751.1784217864@sss.pgh.pa.us> Comments: In-reply-to Maaz Syed Adeeb message dated "Fri, 17 Jul 2026 09:32:10 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3959546.1784310152.1@sss.pgh.pa.us> Date: Fri, 17 Jul 2026 13:42:32 -0400 Message-ID: <3959547.1784310152@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Maaz Syed Adeeb 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