Horton

Re: Bug in pg_describe_object

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>, Andreas Karlsson <andreas@proxel.se>, Joel Jacobson <joel@gluefinance.com>, Magnus Hagander <magnus@hagander.net>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, Jim Nasby <jim@nasby.net>, Herrera Alvaro <alvherre@commandprompt.com>, pgsql-hackers Hackers <pgsql-hackers@postgresql.org>
Date: 2011-01-11T01:56:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add pg_describe_object function

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> My point is that this isn't a bug fix, it's more like moving the
>> goalposts on what getObjectDescription is supposed to do.

> I think that adding the types to the description string is a pretty
> sensible thing to do.

Not really.  AFAIR, there are two cases that exist in practice,
depending on which AM you're talking about:

1. The recorded types match the input types of the operator/function
   (btree & hash).
2. The recorded types are always the same as the opclass's input type
   (gist & gin).

In neither case does printing those types really add much information.
That's why it's not there now.

			regards, tom lane