On Mon, Jul 29, 2024 at 8:17 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> I wrote:
> > I think the page is technically correct, but I'm inclined to duplicate
> > this text from the CREATE DOMAIN page:
>
> > where domain_constraint is:
> > [ CONSTRAINT constraint_name ]
> > { NOT NULL | NULL | CHECK (expression) }
>
> > rather than making readers go look that up.
>
Agreed
> Actually, there *is* a bug in the description, because experimentation
> shows that CREATE DOMAIN accepts NULL in this syntax (as advertised)
> but ALTER DOMAIN does not. We could alternatively decide that that's
> a code bug and make ALTER DOMAIN take it, but I don't think it's worth
> any effort (and this behavior may actually have been intentional, too).
> I think we should just add
>
> where domain_constraint is:
>
> [ CONSTRAINT constraint_name ]
> { NOT NULL | CHECK (expression) }
>
> to the ALTER DOMAIN page, and then remove the claim that it's
> identical to CREATE DOMAIN.
>
>
The inconsistency here and with create/alter table makes me want to make
alter domain work as well. But I agree it isn't really worth the effort
when one is supposed to use "drop not null" to accomplish the effect of
making a domain nullable. But it does open the question of why we document
"alter table alter column add null" - which does not get mentioned as being
a non-standard option on the alter table page.
Both create table and create domain say:
NULL: This clause is only intended for compatibility with nonstandard SQL
databases. Its use is discouraged in new applications.
But then create table goes on to say under Compatibility:
The NULL “constraint” (actually a non-constraint) is a PostgreSQL extension
to the SQL standard ...
But create domain has no matching language; it claims full conformity.
That this "non-constraint" can have a name given seems unusual though done
for ease of syntax I presume.
David J.
