Re: sql_drop Event Trigger

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