Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Date
Msg-id 201206131706.05440.andres@2ndquadrant.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: hint bit i/o reduction
Next
From: Florian Pflug
Date:
Subject: Re: Ability to listen on two unix sockets