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-11T15:59:06Z
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 8:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I don't get it.  If two different items that exist in the system out
> of the box have the same description, it seems clear that relevant
> piece of disambiguating information exists nowhere in the description
> string.

The "relevant piece of disambiguating information" is the function
name+parameters in the first case, or the opclass name in the second.

			regards, tom lane