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 |
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 |