Dimitri Fontaine escribió: > Alvaro Herrera <alvhe...@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.gb4...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
