Horton

Re: Bug in pg_describe_object

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-11T11:20:27Z
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

On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company