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
