| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Haritabh Gupta <haritabh1992(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Florin Irion <irionr(at)gmail(dot)com>, Tim Waizenegger <tim(dot)waizenegger(at)enterprisedb(dot)com> |
| Subject: | Re: [PATCH] pg_get_domain_ddl: DDL reconstruction function for CREATE DOMAIN statement |
| Date: | 2026-02-20 13:24:25 |
| Message-ID: | c8a21f45-098a-42e3-b7dd-f61f5952c283@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-02-18 We 7:10 PM, Tom Lane wrote:
> Haritabh Gupta <haritabh1992(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ilia Evdokimov | 2026-02-20 13:25:24 | Re: Reduce planning time for large NOT IN lists containing NULL |
| Previous Message | Andrey Borodin | 2026-02-20 13:09:23 | Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline |