On Fri, May 3, 2024 at 1:14 AM jian he <jian.universal...@gmail.com> wrote:
> On Fri, May 3, 2024 at 2:47 PM Laurenz Albe <laurenz.a...@cybertec.at> > wrote: > > > > 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. > > > > the system does not translate (check constraint column IS NOT NULL) > to NOT NULL constraint, > at least in domain. > > I'll change this but I was focusing on the fact you get identical user-visible behavior with not null and a check(col is not null). Chain of thought being we discuss the is not null operator (indirectly) already and so not null, which is syntax as opposed to an operation/expression, can leverage that explanation as opposed to getting its own special case. I'll consider this some more and maybe mention the catalog dynamics a bit as well, or at least point to them. > drop domain connotnull cascade; > create domain connotnull integer; > alter domain connotnull add check (value is not null); > \dD > This reminds me, I forgot to add commentary regarding defining a not null constraint on a domain but the domain type surviving a left join but having a null value. David J.
