Re: cataloguing NOT NULL constraints

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.