Re: [PATCH] pg_get_domain_ddl: DDL reconstruction function for CREATE DOMAIN statement - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCH] pg_get_domain_ddl: DDL reconstruction function for CREATE DOMAIN statement
Date
Msg-id c8a21f45-098a-42e3-b7dd-f61f5952c283@dunslane.net
Whole thread Raw
In response to Re: [PATCH] pg_get_domain_ddl: DDL reconstruction function for CREATE DOMAIN statement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2026-02-18 We 7:10 PM, Tom Lane wrote:
> Haritabh Gupta <haritabh1992@gmail.com> writes:
>> Thanks for addressing the comments. I tested v7 and found that
>> type modifiers (typmod) are lost in the base type output.
> 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.
>
> I don't really know what to do about this, but I don't like the
> implementation approach that's being proposed.  I think it's
> loading too much development effort and future maintenance effort
> onto us in comparison to the expected benefit of having these
> functions.



Do you have an alternative suggestion? We could create an extension, but 
keeping that in sync might in fact be harder, and we know from 
experience that extensions are not universally available. That would 
make leveraging these functions for something like Matheus Alcantara's 
schema cloning proposal (as I think Alvaro suggested) pretty much 
impossible.

I'm not sure how much maintenance effort you think will be needed. We 
don't change the shape of database objects all that often.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline
Next
From: Ilia Evdokimov
Date:
Subject: Re: Reduce planning time for large NOT IN lists containing NULL