Re: [PATCH] pg_get_domain_ddl: DDL reconstruction function for CREATE DOMAIN statement

On 2026-Mar-02, Florin Irion wrote:

> On 19/02/26 01:10, Tom Lane wrote:
>
> > This report crystallized something that's been bothering me
> > about not only pg_get_domain_ddl() but all the similar patches
> > that are in the queue. They are adding a large amount of new
> > code that will have to be kept in sync with behavior elsewhere
> > and there is basically zero forcing function to ensure that
> > that happens. Even the rather-overly-voluminous test cases
> > proposed for the functions cannot catch errors of omission,
> > especially not future errors of omission.
>
> v8 adds a PL/pgSQL round-trip harness that captures DDL, drops
> the domain, re-executes the DDL, and ASSERTs the regenerated DDL
> is identical, any suggestions on how to improve it are welcomed.
> This function can be re-used also with other get_<object>_ddl
> as it accepts a parameter for the <object_type>, this way we can
> use some common code.

Hmm, I think this is generally a useful direction, but it feels
incomplete because the developer of some new DDL feature has to remember
to add calls to the regress_verify_ddl_roundtrip() function in the tests
somewhere. We _are_ going to forget.

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?)

With this sort of approach, the developer of a new CREATE feature
doesn't have to remember anything, because that test will break as soon
as they add a test to the stock regression tests when they add some new
feature that the pg_get_blah_ddl() doesn't support. The whole point is
that adding something to the standard regression tests (which is
something we're accustomed to doing) is enough to also cover the
DDL-dumping functions.

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.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Fundamental layering violations tend to bite you on tender
parts of your anatomy." (Tom Lane)
https://postgr.es/m/2818249.1748706121@sss.pgh.pa.us