Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> For Dimitri's patch to add support for dropped objects in event
> triggers, there's an open question about how to report objects that are
> being dropped in a tabular format. What I proposed last had three
> columns: (type, schema, identity). The "type" is a description of the
> object class; I propose the following list:
>
> ...
>
> Ellipses hide uninteresting examples. Opinions on this please?
In my view, it needs to be the same thing as the second part of the
command tag used for commands on the given type of objects.
> Then we have the identity, which is a texualt representation of the
> other stuff needed to uniquely identify the object being referred to.
> For most stuff it's just the name, but for other things it is a bit more
> complex. For example, for a function it'd be the function signature;
> for a table (and for most other object classes) it's the table name.
> For columns, it's the qualified column name i.e.
> <tablename>.<columnname>. Note the schema name never appears here, even
> if the object is not in path; the whole point of this is to be
> machine-parseable and we have the schema separately anyway. So some
> tweaks to functions such as format_type_internal are necessary, to
> supress schema-qualifying when not wanted.
As long as we keep also the name in a separate field, I'm in. Also, that
needs to be properly quoted by the backend (MixedCase, extra dots, etc)
as we just said on an external communication channel.
> I think this kind of machine-parseable object representation would be
> useful for cases other than event triggers, so I am thinking in
> committing this part before the pg_dropped_objects patch. I haven't
> split it out yet from the event triggers patch; I will be sending a
> patch later, in the meantime I welcome comments on the above.
+1
Maybe that can also set the debate for which information to pass down in
Event Trigger User Functions and how. Still don't want to make that a
datatype so that we expose a single variable per object?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
