From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: cataloguing NOT NULL constraints |
Date: | 2023-08-02 08:29:39 |
Message-ID: | 992af0a9-86ee-ecd0-2e12-ed66a1b100dd@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24.07.23 12:32, Alvaro Herrera wrote:
> However, 11.16 (<drop column not null clause> as part of 11.12 <alter
> column definition>), says that DROP NOT NULL causes the indication of
> the column as NOT NULL to be removed. This, to me, says that if you do
> have multiple such constraints, you'd better remove them all with that
> command. All in all, I lean towards allowing just one as best as we
> can.
Another clue is in 11.15 <set column not null clause>, which says
1) Let C be the column identified by the <column name> CN in the
containing <alter column definition>. If the column descriptor of C
does not contain an indication that C is defined as NOT NULL, then:
[do things]
Otherwise it does nothing. So there can only be one such constraint per
table.
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2023-08-02 08:30:00 | Re: add timing information to pg_upgrade |
Previous Message | Hayato Kuroda (Fujitsu) | 2023-08-02 08:13:38 | RE: [PoC] pg_upgrade: allow to upgrade publisher node |