From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tender Wang <tndrwang(at)gmail(dot)com> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Can't find not null constraint, but \d+ shows that |
Date: | 2024-04-09 17:29:03 |
Message-ID: | 202404091729.dls2prtnde6e@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-Mar-29, Tender Wang wrote:
> I think aboved case can explain what's meaning about comments in
> dropconstraint_internal.
> But here, in RemoveConstraintById() , we only care about primary key case,
> so NOT NULL is better to removed from comments.
Actually, I think it's better if all the resets of attnotnull occur in
RemoveConstraintById, for both types of constraints; we would keep that
block in dropconstraint_internal only to raise errors in the cases where
the constraint is protecting a replica identity or a generated column.
Something like the attached, perhaps, may need more polish.
I'm not really sure about the business of adding a new pass value
-- it's clear that things don't work if we don't do *something* -- I'm
just not sure if this is the something that we want to do.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Tiene valor aquel que admite que es un cobarde" (Fernandel)
Attachment | Content-Type | Size |
---|---|---|
0001-Correctly-reset-attnotnull-when-constraints-dropped-.patch | text/x-diff | 13.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-04-09 17:35:51 | macOS Ventura won't generate core dumps |
Previous Message | Daniel Gustafsson | 2024-04-09 17:10:07 | Re: IPC::Run::time[r|out] vs our TAP tests |