Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

From: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Date: 2025-03-13 08:37:47
Message-ID: CAGPqQf36VNRo-yOnGsC1i=2ySgwEsSK5qmup2BYQwAXJMoFLdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 12, 2025 at 11:50 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> On 2025-Mar-12, Rushabh Lathia wrote:
>
> > Hi Alvaro,
> >
> > Here are the latest patches, which includes the regression fix.
>
> Thank you.
>
> Taking a step back after discussing this with some colleagues, I need to
> contradict what I said at the start of this thread. There's a worry
> that changing pg_attribute.attnotnull in the way I initially suggested
> might not be such a great idea after all. I did a quick search using
> codesearch.debian.net for applications reading that column and thinking
> about how they would react to this change; I think in the end it's going
> to be quite disastrous. We would break a vast number of these apps, and
> there are probably countless other apps and frameworks that we would
> also break. Everybody would hate us forever. Upgrading to Postgres 18
> would become as bad an experience as the drastic change of implicit
> casts to text in 8.3. Nothing else in the intervening 17 years strikes
> me as so problematic as this change would be.
>
> So I think we may need to go back and somehow leave pg_attribute alone,
> to avoid breaking the whole world. Maybe it would be sufficient to
> change the CompactAttribute->attnotnull to no longer be a boolean, but
> the new char representation instead. I'm not sure if this would
> actually work.
>

Thank you for your feedback. I understand that this change could be
problematic

for existing applications, as attnotnull is a highly generic catalog
column. I will

revisit the patch, make the necessary adjustments, and submit a revised
version

accordingly.

I appreciate your insights and will try to submit the new patch.

Regards,
Rushabh Lathia
www.EnterpriseDB.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-03-13 08:42:07 RE: long-standing data loss bug in initial sync of logical replication
Previous Message Steven Niu 2025-03-13 08:36:58 Re: [Patch] remove duplicated smgrclose