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/[email protected]
