Feedback-ID: ie0a040ee:Fastmail
Message-ID: <471cd41b-c345-3bee-fe97-061f74eba5b8@eisentraut.org>
Date: Tue, 5 Sep 2023 13:29:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.15.0
Subject: Re: cataloguing NOT NULL constraints
Content-Language: en-US
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
References: <20230831100239.gzjmiovzabx2diuo@alvherre.pgsql>
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <20230831100239.gzjmiovzabx2diuo@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/471cd41b-c345-3bee-fe97-061f74eba5b8%40eisentraut.org>
Precedence: bulk

On 31.08.23 12:02, Alvaro Herrera wrote:
> In constraint_column_usage, you're adding a relkind to the catalog scan
> that goes through pg_depend for CHECK constraints.  Here we can rely on
> a simple conkey[1] check and a separate UNION ALL arm[q5]; this is also
> faster when there are many tables.
> 
> The third view definition looks ok.  It's certainly very nice to be able
> to delete XXX comments there.

The following information schema views are affected by the not-null 
constraint catalog entries:

1. CHECK_CONSTRAINTS
2. CONSTRAINT_COLUMN_USAGE
3. DOMAIN_CONSTRAINTS
4. TABLE_CONSTRAINTS

Note that 1 and 3 also contain domain constraints.  So as long as the 
domain not-null constraints are not similarly catalogued, we can't 
delete the separate not-null union branch.  (3 never had one, so 
arguably a bit buggy.)

I think we can fix up 4 by just deleting the not-null union branch.

For 2, the simple fix is also easy, but there are some other options, as 
you discuss above.

How do you want to proceed?