Dimitri Fontaine escribió:
> Alvaro Herrera <alvherre@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