Skip site navigation (1) Skip section navigation (2)

Re: cataloguing NOT NULL constraints

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cataloguing NOT NULL constraints
Date: 2011-08-03 07:11:32
Message-ID: CAEZATCVjtQbxXTVhdYjRJ7Zbp7+Lv6=rFBqU2E_RbGnSSJ2FBg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 3 August 2011 04:40, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
>
>> Looks pretty good to me (not too dirty). I suppose given that the
>> parser transforms AT_ColumnConstraint into one of the existing command
>> subtypes, you could just have gram.y emit an AT_AddConstraint with the
>> ColumnDef attached, to save adding a new subtype, but there's probably
>> not much difference.
>
> 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.

I wasn't proposing getting rid of that bit in parse_utilcmd. I just
meant move the block that calls transformColumnConstraints() to the
AT_AddConstraint case in transformAlterTableStmt(). So it would test
if it has a ColumnDef attached, and either process a table constraint
or a set of column constraints. That would avoid the need for a new
command subtype, and so the changes to tablecmds.c would not be
needed. I think it would also avoid the need to add colname to the
Constraint struct, so none of the parsenodes.h changes would be needed
either.


  (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.

Oh I keep forgetting about domains. But after a quick glance at the
docs, doesn't it already have syntax for this?

Regards,
Dean

In response to

Responses

pgsql-hackers by date

Next:From: Alexander KorotkovDate: 2011-08-03 08:18:49
Subject: Re: WIP: Fast GiST index build
Previous:From: Alvaro HerreraDate: 2011-08-03 03:53:12
Subject: Re: WAL logging volume and CREATE TABLE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group