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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
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-12 18:20:13
Message-ID: 202503121820.lbusvkv4oa6u@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-03-12 18:32:07 Re: [PATCH] SVE popcount support
Previous Message Nathan Bossart 2025-03-12 18:19:09 Re: remove open-coded popcount in acl.c