Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > I'm very unsure about that idea. In any case the proposed name seems > way too general. Maybe we could have a separate datatype for objects > being dropped, which would be specific to > pg_event_trigger_dropped_objects(), and not try to mix it with other > events' info; but really I don't see much point in a tailored datatype > when we can simply declare the right set of columns to the function in > the first place.
I'm not too sure about it either, it's just an excuse to keep the two places in sync (TG_* and the pg_event_trigger_dropped_objects() return type). > Hmm, it includes a completely different implementation to get at the > object name and schema (I didn't know I had written that previous one -- > how ironic), but it doesn't include the "obtypename" (your term) which > is what I want here. (BTW I don't like "obtypename" at all; how about > "object_type"?) So we would have "object_type", "object_name", > "object_schema". IIRC obtypename is not my choice, it already is named that way in the code, maybe not in user visible places, though. > 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? 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. 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. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
