Horton

Re: Bug in pg_describe_object

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andreas Karlsson <andreas@proxel.se>
Cc: Joel Jacobson <joel@gluefinance.com>, Josh Berkus <josh@agliodbs.com>, Robert Haas <robertmhaas@gmail.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-12T00:14:58Z
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

Andreas Karlsson <andreas@proxel.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.

			regards, tom lane