Date: Wed, 30 Aug 2023 09:46:58 +0900 (JST)
Message-Id: <20230830.094658.631998719913738330.horikyota.ntt@gmail.com>
To: alvherre@alvh.no-ip.org
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Strange presentaion related to inheritance in \d+
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <20230829172828.5qi2pfbladvfgvsg@alvherre.pgsql>
References: <20230829.135334.377739201526442411.horikyota.ntt@gmail.com>
	<20230829172828.5qi2pfbladvfgvsg@alvherre.pgsql>
User-Agent: Mew version 6.8 on Emacs 27.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20230830.094658.631998719913738330.horikyota.ntt%40gmail.com>
Precedence: bulk

At Tue, 29 Aug 2023 19:28:28 +0200, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in 
> On 2023-Aug-29, Kyotaro Horiguchi wrote:
> 
> > Attached is the initial version of the patch. It prevents "CREATE
> > TABLE" from executing if there is an inconsisntent not-null
> > constraint.  Also I noticed that "ALTER TABLE t ADD NOT NULL c NO
> > INHERIT" silently ignores the "NO INHERIT" part and fixed it.
> 
> Great, thank you.  I pushed it after modifying it a bit -- instead of
> throwing the error in MergeAttributes, I did it in
> AddRelationNotNullConstraints().  It seems cleaner this way, mostly
> because we already have to match these two constraints there.  (I guess

I agree that it is cleaner.

> you could argue that we waste catalog-insertion work before the error is
> reported and the whole thing is aborted; but I don't think this is a
> serious problem in practice.)

Given the rarity and the speed required, I agree that early-catching
is not that crucial here. Thanks for clearing that up.

regardes.


-- 
Kyotaro Horiguchi
NTT Open Source Software Center