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