Re: cataloguing NOT NULL constraints - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: cataloguing NOT NULL constraints
Date
Msg-id 1312480674.24208.8.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: cataloguing NOT NULL constraints  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: cataloguing NOT NULL constraints
Re: cataloguing NOT NULL constraints
List pgsql-hackers
On tis, 2011-08-02 at 23:40 -0400, Alvaro Herrera wrote:
> Thanks.  I've done the other changes you suggested, but I don't see that
> it's desirable to have gram.y emit AT_AddConstraint directly.  It seems
> cleaner to be able to turn a NOT NULL constraint into AT_SetNotNull
> in parse_utilcmd instead.  (Maybe I'll have to bite the bullet and make
> AT_AddConstraint work for not null constraints as well, as part of the
> larger patch.  Not sure.)  Currently, the table constraint syntax only
> lets you do a single constraint at a time, but you can do multiple
> constraints with the column constraint syntax.  I am not sure how hard
> it is to rework the grammar so that only a single constraint is
> allowed, but I'm not sure that it's worth the trouble either.
> 
> Attached is an updated version, touching the docs and adding a new
> simple regression test.
> 
> But ... I just noticed that I need to touch ALTER DOMAIN in a similar
> way as well.

Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser to convert "x CHECK (x IS
NOT NULL)" to "x NOT NULL".  It seems to me that we're adding a whole
lot of hoopla here that is essentially identical to the existing CHECK
constraint support (it must be, per SQL standard), for no additional
functionality.



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Next
From: Peter Eisentraut
Date:
Subject: Re: TRUE/FALSE vs true/false