Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id B7C45B5DBDC for ; Thu, 4 Aug 2011 14:58:03 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 07139-07 for ; Thu, 4 Aug 2011 17:57:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mail.postgresql.org (Postfix) with SMTP id 52992B5DBC1 for ; Thu, 4 Aug 2011 14:57:57 -0300 (ADT) Received: (qmail invoked by alias); 04 Aug 2011 17:57:56 -0000 Received: from a88-115-218-165.elisa-laajakaista.fi (EHLO [10.0.0.102]) [88.115.218.165] by mail.gmx.net (mp020) with SMTP; 04 Aug 2011 19:57:56 +0200 X-Authenticated: #495269 X-Provags-ID: V01U2FsdGVkX197dgR300x7atTktBxP+1TU6RlJazE5tb0QMYnRuU zWW2+bZhZpKaWK Subject: Re: cataloguing NOT NULL constraints From: Peter Eisentraut To: Alvaro Herrera Cc: Dean Rasheed , Robert Haas , Pg Hackers In-Reply-To: <1312342392-sup-7189@alvh.no-ip.org> References: <20110707213401.GA27098@alvh.no-ip.org> <1311291819-sup-6206@alvh.no-ip.org> <1311367030-sup-9426@alvh.no-ip.org> <1311985058-sup-952@alvh.no-ip.org> <1312342392-sup-7189@alvh.no-ip.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 04 Aug 2011 20:57:54 +0300 Message-ID: <1312480674.24208.8.camel@vanquo.pezone.net> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.615 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.716 X-Spam-Level: X-Archive-Number: 201108/213 X-Sequence-Number: 192968 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.