Re: cataloguing NOT NULL constraints

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cataloguing NOT NULL constraints
Date: 2011-08-04 17:57:54
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-08-04 18:00:11 Re: TRUE/FALSE vs true/false
Previous Message Phil Sorber 2011-08-04 17:53:39 Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c