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