Alvaro Herrera <alvherre@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
