Re: Bug in pg_describe_object

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, Joel Jacobson <joel(at)gluefinance(dot)com>, Josh Berkus <josh(at)agliodbs(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-12 01:42:35
Message-ID: AANLkTimH=DhKHXScaksVW+9ozRGg8hE04cmPs7gyMJ=-@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 11, 2011 at 7:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andreas Karlsson <andreas(at)proxel(dot)se> writes:
>> On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
>>> It really shouldn't be useful to include those.  Attend what it says in
>>> the fine manual for CREATE OPERATOR CLASS:
>
>> Hm, that is not what I see when reading the source.
>
>> There can exist several entries in pg_amproc for one operator family
>> with the same short_number and function (both name and types).
>
> We're cheating in a small number of places by using a binary-compatible
> hash function to implement hashing for a datatype other than the one
> it's declared to work on.  I don't think that the existence of that hack
> means that getObjectDescription should bloat the descriptions of every
> amproc entry with generally-useless information.

I don't see how you can claim that it's remotely sane for different
objects to have the same description. The whole point is that someone
is going to say "DROP something" and the system is going to say "no,
there's an object that depends on it", and the description it gives
won't uniquely identify which one. If the information is needed to
distinguish which object is implicated, it's not useless. The fact
that someone with an expert-level knowledge of PostgreSQL and a
divining rod may be able to determine which object they should be
worried about given only half of its primary key fields is not a good
reason to omit the other half. In fact, there isn't any such reason,
and you're the only one arguing otherwise.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2011-01-12 02:00:12 Re: Allowing multiple concurrent base backups
Previous Message Robert Haas 2011-01-12 01:31:29 Re: LOCK for non-tables