Re: cataloguing NOT NULL constraints

On 2022-Sep-19, Matthias van de Meent wrote:

> I'm not sure on the 'good' part of this alternative, but we could go
> with a single row-based IS NOT NULL to reduce such clutter, utilizing
> the `ROW() IS NOT NULL` requirement of a row only matching IS NOT NULL
> when all attributes are also IS NOT NULL:
> 
>     Check constraints:
>         "tab_notnull_check" CHECK (ROW(a, b, c, d, e) IS NOT NULL)

There's no way to mark this NOT VALID individually or validate it
afterwards, though.

> But the performance of repeated row-casting would probably not be as
> good as our current NULL checks

The NULL checks would still be mostly done by the attnotnull checks
internally, so there shouldn't be too much of a difference.

.. though I'm now wondering if there's additional overhead from checking
the constraint twice on each row: first the attnotnull bit, then the
CHECK itself.  Hmm.  That's probably quite bad.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/