Horton

Re: enhanced error fields

Peter Eisentraut <peter_e@gmx.net>

View thread
From: Peter Eisentraut <peter_e@gmx.net>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "anarazel@anarazel.de" <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2013-01-28T21:33:50Z
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. Create a "sort support" interface API for faster sorting.

On 1/5/13 12:48 PM, Peter Geoghegan wrote:
>> is there agreement of routine_name and trigger_name fields?
> Well, Tom and I are both opposed to including those fields. Peter E
> seemed to support it in some way, but didn't respond to Tom's
> criticisms (which were just a restatement of my own). So, it seems to
> me that we're not going to do that, assuming nothing changes.

Another point, in case someone wants to revisit this in the future, is
that these fields were applied in a way that is contrary to the SQL
standard, I think.

The presented patch interpreted ROUTINE_NAME as: the error happened
while executing this function.  But according to the standard, the field
is only set when the error was directly related to the function itself,
for example when calling an INSERT statement in a non-volatile function.
 This is consistent with how, for example, TABLE_NAME is set when the
error is about the table, not just happened while reading the table.