From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_dump misses comments on NOT NULL constraints |
Date: | 2025-06-25 13:36:34 |
Message-ID: | 202506251336.qzlvt5yaz2cs@alvherre.pgsql |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-Jun-25, Álvaro Herrera wrote:
> Yeah, I think in this case we need to extract the constraint name so
> that we have it available to print the COMMENT command, rather than
> making any assumptions about it. In fact I suspect this would fail if
> the table or column names are very long. For the other pg_dump uses of
> this logic it doesn't matter AFAIR, but here I think we must be
> stricter.
As attached.
I'm bothered by this not having any tests -- I'll see about adding some
after lunch. But at least, this seems to be dumped correctly:
CREATE TABLE supercallifragilisticexpialidocious ("dociousaliexpilistic fragilcalirupus" int not null);
COMMENT ON CONSTRAINT "supercallifragilisticexpial_dociousaliexpilistic fragi_not_null" ON public.supercallifragilisticexpialidocious IS 'long names, huh?';
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Attachment | Content-Type | Size |
---|---|---|
v3-0001-fix-pg_dump-not-dump-comments-on-not-null-constra.patch | text/x-diff | 8.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Shinderuk | 2025-06-25 13:41:46 | Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum) |
Previous Message | Tomas Vondra | 2025-06-25 12:53:41 | Re: pgsql: Introduce pg_shmem_allocations_numa view |