Feedback-ID: ia2694551:Fastmail
Date: Thu, 11 Apr 2024 11:10:17 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: jian he <jian.universality@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Can't find not null constraint, but \d+ shows that
Message-ID: <202404110910.dbwfcz47kpth@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACJufxFfcqScDSXTfM8BKMGbNdy1v0fcrEZHRR5BejtOTceG+A@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202404110910.dbwfcz47kpth%40alvherre.pgsql>
Precedence: bulk

On 2024-Apr-11, jian he wrote:

> now I figured out that
> dropping a column of primary key columns will not change other key
> columns'  "not null" property.
> dropping the primary key associated constraint will make all key
> columns "not null" property disappear.

Well, I think you were right that we should try to handle the situation
of unmarking attnotnull as much as possible, to decrease the chances
that the problematic situation occurs.  That means, we can use the
earlier code to handle DROP COLUMN when it causes a PK to be dropped --
even though we still need to handle the situation of an attnotnull flag
set with no pg_constraint row.  I mean, we still have to handle DROP
DOMAIN correctly (and there might be other cases that I haven't thought
about) ... but surely this is a much less common situation than the one
you reported.  So I'll merge everything and post an updated patch.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree.              (Don Knuth)