Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: pgsql-hackers@postgresql.org
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2012-06-13T15:06:05Z
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 →
-
Mark JSON error detail messages for translation.
- 36b7e3da17bc 9.2.0 cited
On Wednesday, June 13, 2012 05:03:38 PM Robert Haas wrote: > On Wed, Jun 13, 2012 at 10:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> On Tue, Jun 12, 2012 at 9:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> The code for this is as attached. Note that I'd rip out the > >>> normal-path tracking of line boundaries; it seems better to have a > >>> second scan of the data in the error case and save the cycles in > >>> non-error cases. > >> > >> Really?! > > > > Um ... do you have a problem with that idea, and if so what? It would > > be considerably more complicated to do it without a second pass. > > Could you explain how it's broken now, and why it will be hard to fix? > People may well want to use a cast to JSON within an exception block > as a way of testing whether strings are valid JSON. We should not > assume that the cost of an exception is totally irrelevant, because > this might be iterated. Exception blocks/subtransctions already are considerably expensive. I have a hard time believing this additional cost would be measureable. Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services