Dimitri Fontaine escribió: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> > Another question. If I do ALTER TABLE foo DROP COLUMN bar, do we need > > to fire an event trigger for the dropped column? Right now we don't, > > ISTM we should. And if we want that, then the above set of three > > properties doesn't cut it. > > Do we paint ourselves in a corner by not supporting columns in the first > release? Well, the main distinction is that there's no space to refer to them in the current implementation, for lack of objectSubId or (more likely) column name. > Table columns are proper SQL level objects in that they have their own > catalog entry and OID and a set of commands to manage them, but that set > of command is in fact a *subset* of ALTER TABLE. Table columns do not have OIDs; you refer to them by (objectId, objectSubId). The latter is an integer that references pg_attribute.attnum. I am only wondering about ways to drop things at present, without concern for whether it's a straight DROP FOO command or ALTER, etc. > It feels like drifting > a little more into the land of exposing PostgreSQL internals in a way, > so I'm not too sure about the proper answer here. Mumble. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
