Re: Bug in pg_describe_object

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Joel Jacobson <joel(at)gluefinance(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Jim Nasby <jim(at)nasby(dot)net>, Herrera Alvaro <alvherre(at)commandprompt(dot)com>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in pg_describe_object
Date: 2011-01-11 15:59:06
Message-ID: 18558.1294761546@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-11 16:03:42 Re: Fwd: [TESTERS] [TEST REPORT] 9.1Alpha3 Feature E.1.4.7.2 in release notes.
Previous Message Dimitri Fontaine 2011-01-11 15:57:37 Re: Add function dependencies