Re: Document NULL
| От | David G. Johnston |
|---|---|
| Тема | Re: Document NULL |
| Дата | |
| Msg-id | CAKFQuwa5CWo61gzrx20-OAdy7vPpTuGYO968nRbR03d==M=XaA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Document NULL (jian he <jian.universality@gmail.com>) |
| Список | pgsql-hackers |
On Fri, May 3, 2024 at 1:14 AM jian he <jian.universality@gmail.com> wrote:
On Fri, May 3, 2024 at 2:47 PM Laurenz Albe <laurenz.albe@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.
В списке pgsql-hackers по дате отправления: