Dimitri Fontaine escribió:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Do we want some more stuff provided by pg_dropped_objects? We now have
> > classId, objectId, objectSubId, object name, schema name. One further
> > thing I think we need is the object's type, i.e. a simple untranslated
> > string "table", "view", "operator" and so on. AFAICT this requires a
> > nearly-duplicate of getObjectDescription.
>
> About what missing information to add, please review:
>
> http://wiki.postgresql.org/wiki/Event_Triggers#How_to_expose_Information_to_Event_Triggers_Functions
>
> I'd like us to provide the same set of extra information from within
> classic Event Triggers and in the records returned by the function.
>
> Maybe a good idea would be to create a datatype for that, and publish a
> single TG_DETAILS variable from within Event Triggers, of that type, and
> have the pg_dropped_objects() function return a setof that type?
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.
> About the implementation and the getObjectDescription() remark, please
> have a look at your latest revision of the other patch in the series,
>
> http://www.postgresql.org/message-id/20130109165829.GB4490@alvh.no-ip.org
>
> I think it provides exactly what you need here, and you already did
> cleanup my work for getting at that…
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".
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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services