Excerpts from Dean Rasheed's message of mié ago 03 03:11:32 -0400 2011: > On 3 August 2011 04:40, Alvaro Herrera <alvhe...@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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
