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

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-11 07:19:35
Message-ID: CAHewXNk5m95hu8MSmKX4QFb2UK+uuARm4W8PtQs-unSt=XiaTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

jian he <jian(dot)universality(at)gmail(dot)com> 于2024年4月11日周四 14:40写道:

> On Wed, Apr 10, 2024 at 2:10 PM jian he <jian(dot)universality(at)gmail(dot)com>
> wrote:
> >
> > DROP TABLE if exists notnull_tbl2;
> > CREATE TABLE notnull_tbl2 (c0 int generated by default as IDENTITY, c1
> int);
> > ALTER TABLE notnull_tbl2 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > ALTER TABLE notnull_tbl2 DROP CONSTRAINT notnull_tbl2_c0_not_null;
> > ALTER TABLE notnull_tbl2 DROP c1;
> > \d notnull_tbl2
>
> > ALTER TABLE notnull_tbl2 DROP CONSTRAINT notnull_tbl2_c0_not_null;
> per above sequence execution order, this should error out?
>
> otherwise which "not null" (attribute|constraint) to anchor "generated
> by default as identity" not null property?
> "DROP c1" will drop the not null property for "c0" and "c1".
> if "DROP CONSTRAINT notnull_tbl2_c0_not_nul" not error out, then
> " ALTER TABLE notnull_tbl2 DROP c1;"
> should either error out
> or transform "c0" from "c0 int generated by default as identity"
> to
> "c0 int"
>
> I try above case on MASTER and MASTER with Alvaro V2 patch, and all work
correctly.
\d+ notnull_tbl2 will see not-null of "c0".

>
> On Thu, Apr 11, 2024 at 1:23 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
> >
> > On 2024-Apr-10, Alvaro Herrera wrote:
> >
> > > One thing missing here is pg_dump support. If you just dump this
> table,
> > > it'll end up with no constraint at all. That's obviously bad, so I
> > > propose we have pg_dump add a regular NOT NULL constraint for those, to
> > > avoid perpetuating the weird situation further.
> >
> > Here's another crude patchset, this time including the pg_dump aspect.
> >
>
> +DROP TABLE notnull_tbl1;
> +-- make sure attnotnull is reset correctly when a PK is dropped indirectly
> +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1));
> +ALTER TABLE notnull_tbl1 DROP c1;
> +\d+ notnull_tbl1
> + Table "public.notnull_tbl1"
> + Column | Type | Collation | Nullable | Default | Storage | Stats
> target | Description
>
> +--------+---------+-----------+----------+---------+---------+--------------+-------------
> + c0 | integer | | not null | | plain |
> |
> +
>
> this is not what we expected?
> "not null" for "c0" now should be false?
> am I missing something?
>
Yeah, now this is expected behavior.
Users can drop manually not-null of "c0" if they want, and no error
reporte.

--
Tender Wang
OpenPie: https://en.openpie.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2024-04-11 07:57:12 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Previous Message Ashutosh Bapat 2024-04-11 06:54:37 Re: apply_scanjoin_target_to_paths and partitionwise join