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
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.
