On Tue, Mar 11, 2025 at 6:21 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
>
> > seems didn't cover "initially immediate" case for domain.
> > for example:
> > create domain d_int as int4;
> > --- the following two cases should fail.
> > alter domain d_int add constraint nn1 not null initially immediate;
> > alter domain d_int add constraint cc check(value > 1) initially immediate;
>
> Yeah, I thought at first you were right, but on further thought, do we
> really want to do this? I mean, INITIALLY IMMEDIATE is the default
> timing for a constraint, so why should we complain if a user wants to
> get a constraint that's declared that way? I'm not sure that we should
> do it. Same with NOT DEFERRABLE.
> [... looks at the standard doc ...]
> And that's indeed what the SQL standard says:
>
> <domain definition> ::=
> CREATE DOMAIN <domain name> [ AS ] <predefined type>
> [ <default clause> ]
> [ <domain constraint>... ]
> [ <collate clause> ]
>
> <domain constraint> ::=
> [ <constraint name definition> ] <check constraint definition> [ <constraint characteristics> ]
>
> 8) For every <domain constraint> specified:
> [...]
> b) If <constraint characteristics> is not specified, then INITIALLY IMMEDIATE
> NOT DEFERRABLE is implicit.
>
>
> So I think the fix here needs to distinguish those cases and avoid
> throwing errors for them.
>
> (Note also it does not say that INITIALLY DEFERRED or DEFERRABLE are
> disallowed, which means that we're failing to fully implement the
> standard-mandated behavior by prohibiting those.)
>
I don't have a huge opinion though.
but it's better to align CREATE DOMAIN with ALTER DOMAIN.
For example, the following two logic should behave the same.
create domain d_int as int4 constraint nn1 not null initially immediate;
alter domain d_int add constraint nn1 not null initially immediate;
Also if we do not error out, then in the create_domain.sgml, alter_domain.sgml
<synopsis> section we should include these "useless" keywords.
