On Tue, Mar 11, 2025 at 6:21 PM Álvaro Herrera <alvhe...@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.
