Horton

Re: Bug in pg_describe_object

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Joel Jacobson <joel@gluefinance.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>, AndreasKarlsson <andreas@proxel.se>, Magnus Hagander <magnus@hagander.net>, DimitriFontaine <dimitri@2ndquadrant.fr>, Jim Nasby <jim@nasby.net>, Herrera Alvaro <alvherre@commandprompt.com>, pgsql-hackers Hackers <pgsql-hackers@postgresql.org>
Date: 2011-01-11T13:52:12Z
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

On Jan 11, 2011, at 8:25 AM, Joel Jacobson <joel@gluefinance.com> wrote:
> 2011/1/11 Robert Haas <robertmhaas@gmail.com>:
>> 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.
> 
> I guess it is a question of prioritization.
> If backwards compatibility is to be guaranteed, even for functions
> returning text intended to be read by humans, then the function cannot
> be modified, without violating that golden rule, if such a rule exists
> within the PostgreSQL development project?
> 
> If it's not a golden rule, then it's a totally different story and
> there is no excuse why it should return the same descriptions for the
> same objects.
> Any other reasoning is just silly.

Well, we shouldn't change them randomly or arbitrarily, but improving them is another thing altogether.  I think the contention that any user or application anywhere is depending on the exact textual representation of a pg_amproc entry is exceedingly dubious.  And I think the current messages are flat-out confusing.

...Robert