Re: Can't find not null constraint, but \d+ shows that

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

In response to

Responses

Browse pgsql-hackers by date

  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