Re: [PATCH] pg_get_domain_ddl: DDL reconstruction function for CREATE DOMAIN statement
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Florin Irion <irionr@gmail.com>, Haritabh Gupta <haritabh1992@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2026-03-02T18:56:22Z
Lists: pgsql-hackers
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes: > I think it would be more helpful to have a test module that > 1. installs an event trigger on ddl_command_end for CREATE for > object being created > 2. runs all the tests in parallel_schedule > 3. do [... something ...] with the event trigger to generate the DDL > using the new functions, and compare with the object created > originally. (There's a lot of handwaving here. Maybe pg_dump both > and compare?) While I agree that automating this might be helpful, please please please do not create yet another execution of the core regression tests. There is far too much stuff in there that is not DDL and will only be useless cycles for this purpose. I wonder if it'd be practical to extract just the DDL commands from the core scripts, and then run just those through a process like you suggest? I agree that the "handwaving" part is trickier than it looks. If memory serves, we've had bugs-of-omission where somebody forgot to update pg_dump for some new feature, and it wasn't obvious because comparing pg_dump output against pg_dump output didn't show that the relevant object property wasn't copied correctly. In this context, forgetting to update both pg_dump and the DDL-dumping function would mask both omissions. Maybe that's unlikely, but ... > Another possibility is to use the pg_dump/t/002_pg_dump.pl database > instead of the stock regression one, which is perhaps richer in object > type diversity. I think that test script also suffers from the out-of-sight, out-of-mind problem. Not to mention that you need a lot of study to figure out how to modify it at all. I certainly avoid doing so. regards, tom lane