Re: machine-parseable object descriptions

Dimitri Fontaine wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > All in all, I'm happy with this and I'm considering committing it as
> > soon as we agree on the set of columns.  I'm mildly on the side of
> > removing the separate schema column and keeping name, so we'd have
> > type/name/identity.
>
> I would prefer that we keep the schema column, for easier per-schema
> processing or filtering. It's way eaiser to provide it in a separate
> column than to ask people to parse it back from the identity column.

Okay.

Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > The new identity column is amazingly verbose on things like pg_amproc entries:
>
> >  10650 | 1 (pg_catalog.point, pg_catalog.point) of pg_catalog.point_ops for gist:
pg_catalog.gist_point_consistent(pg_catalog.internal,pg_catalog.point,integer,pg_catalog.oid,pg_catalog.internal)
>
> Uh ... isn't that confusing the *identity* of the pg_amproc entry with
> its *content*?  I would say that the function reference doesn't belong
> there.  You do need the rest.  I would also suggest that you prepend
> the word "function" (or "operator" for pg_amop), so that it reads like
> "function 1 (typename, typename) of opfamilyname for amname".

Uhm, yeah, fixed.

So here's a final version of the patch.  With docs too.

One change I made was to move all the new code from dependency.c into
objectaddress.c.  The only reason it was in dependency.c was that
getObjectDescription was there in the first place; but it doesn't seem
to me that it really belongs there.  (Back when it was first created,
there was no objectaddress.c at all, and dependency.c was the only user
of it.)  If there were no backpatching considerations, I would suggest
we move getObjectDescription() to objectaddress.c as well, but I'm not
sure it's worth the trouble, but I'm not wedded to that if somebody
thinks both things should be kept together.

Finally: it'd be nice to be able to get pg_am identities with these
functions too.  Then you could use a simple query to get object
identities + descriptions from pg_description (right now you have to
exclude that catalog specifically, otherwise the query bombs out).  But
it'd be a lot of trouble, and since these objects are not really
pluggable, I'm not bothering.  We can always add it later if there's
more interesting use for it.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services