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

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

In response to

Browse pgsql-hackers by date

  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