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

From Alvaro Herrera
Subject Re: cataloguing NOT NULL constraints
Date
Msg-id 1312391235-sup-1794@alvh.no-ip.org
Whole thread Raw
In response to Re: cataloguing NOT NULL constraints  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: cataloguing NOT NULL constraints
List pgsql-hackers
Excerpts from Dean Rasheed's message of mié ago 03 03:11:32 -0400 2011:
> On 3 August 2011 04:40, Alvaro Herrera <alvherre@commandprompt.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.

Oh, I see.  Well, the problem is precisely that we don't have a
ColumnDef at that point.

... ah, maybe what we could do is have gram.y create a ColumnDef in the
new production, and stick that in cmd->def instead of the list of
constraints.  So parse_utilcmd would have to know that if that node
IsA(ColumnDef) then it needs to deal with column constraints.  It seems
a bit cleaner overall, though it's still wart-ish.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: WIP fix proposal for bug #6123
Next
From: Robert Haas
Date:
Subject: Re: WIP fix proposal for bug #6123