Feedback-ID: ie0a040ee:Fastmail
Message-ID: <f88ddb82-1d6d-459d-8b9f-e75f07977ec3@eisentraut.org>
Date: Thu, 3 Apr 2025 17:03:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT
 NULL constraints
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: jian he <jian.universality@gmail.com>, Robert Haas
 <robertmhaas@gmail.com>, Rushabh Lathia <rushabh.lathia@gmail.com>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <202504030807.sj5yexcmrgpq@alvherre.pgsql>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <202504030807.sj5yexcmrgpq@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/f88ddb82-1d6d-459d-8b9f-e75f07977ec3%40eisentraut.org>
Precedence: bulk

On 03.04.25 10:07, Alvaro Herrera wrote:
> The new flag is there for quick access by get_relation_info.  We could
> easily not have it otherwise, because clients don't need it, but its
> lack would probably make planning measurably slower because it'd have to
> do syscache access for every single not-null constraint to figure out if
> it's valid or not.

In the v6 patch, you are adding a attnullability field to the 
CompactAttribute in the tuple descriptor and use that in 
get_relation_info().  That seems like the right approach, because then 
you're doing all that preprocessing about which constraint is active in 
the relcache.  So I don't see where the extra pg_attribute field 
attnotnullvalid is getting used.