Re: pg_dump does not dump domain not-null constraint's comments

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump does not dump domain not-null constraint's comments
Date: 2025-05-07 14:37:27
Message-ID: CACJufxEkn5s6-8H_Jao0ChtMo_mhOqkxXMAZmLyW6zPgtMp6Fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 7, 2025 at 5:25 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> On 2025-May-07, jian he wrote:
>
> > in PG17 and master, pg_dump (--schema=test --no-owner)
> > [...]
> > didn't produce
> > COMMENT ON CONSTRAINT nn ON DOMAIN test.d1 IS 'not null constraint on
> > domain d1';
> > we should make pg_dump to produce it too?
>
> Yes, this is clearly a pg17 bug whose fix should be backpatched.
>
> > The attached patch tries to make it produce comments on not-null
> > constraints on domains.
>
> Thanks, I'll have a look.
>
> > I aslo renamed struct TypeInfo fields, nDomChecks will be renamed to
> > nDomConstrs; domChecks will be renamed to domConstrs.
> > TypeInfo->domConstrs will also include not-null constraint
> > information, changing from domChecks to domConstrs makes sense, IMHO.
>
> Hmm, for a backpatch I would leave the field names alone since they are
> publicly visible; we can rename separately in pg19 once it opens. Can
> you resubmit splitting the renaming out to a 0002 patch?
>
> --
hi.

i didn't fully understand pg_dump perl dump test, I have added some changes on
src/bin/pg_dump/t/002_pg_dump.pl, but it fails the tests....

v2-0001 ensures pg_dump dump domain not-null constraint's comments
v2-0002 change some variable/argument/struct element name because of v2-0001.

Attachment Content-Type Size
v2-0001-pg_dump-does-not-dump-domain-not-null-constraint-.patch text/x-patch 7.3 KB
v2-0002-sanitize-variable-or-argument-name-in-pg_dump.patch text/x-patch 3.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-05-07 14:51:19 Re: Horribly slow pg_upgrade performance with many Large Objects
Previous Message Greg Sabino Mullane 2025-05-07 14:29:43 Re: regdatabase