On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
