Re: Document NULL

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Document NULL
Date: 2024-05-03 06:47:20
Message-ID: 18be3aceacb301820313c683040317d559d66cb7.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2024-05-02 at 08:23 -0700, David G. Johnston wrote:
> Version 2 attached.  Still a draft, focused on topic picking and overall structure.

I'm fine with most of the material (ignoring ellipses and typos), except this:

+ The NOT NULL column constraint is largely syntax sugar for the corresponding
+ column IS NOT NULL check constraint, though there are metadata differences
+ described in create table.

I see a substantial difference there:

SELECT conname, contype,
pg_get_expr(conbin, 'not_null'::regclass)
FROM pg_constraint
WHERE conrelid = 'not_null'::regclass;

conname │ contype │ pg_get_expr
══════════════════════╪═════════╪══════════════════
check_null │ c │ (id IS NOT NULL)
not_null_id_not_null │ n │ ∅
(2 rows)

There is also the "attnotnull" column in "pg_attribute".

I didn't try it, but I guess that the performance difference will be measurable.
So I wouldn't call it "syntactic sugar".

Perhaps: The behavior of the NOT NULL constraint is like that of a check
constraint with IS NOT NULL.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2024-05-03 08:07:45 different engine for JIT
Previous Message Anthonin Bonnefoy 2024-05-03 06:41:42 Re: Fix parallel vacuum buffer usage reporting