Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.

On Wednesday, June 13, 2012 05:18:22 PM Robert Haas wrote:
> On Wed, Jun 13, 2012 at 11:06 AM, Andres Freund <andres@2ndquadrant.com> 
wrote:
> > 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.
> 
> According to my testing, the main cost of an exception block catching
> a division-by-zero error is that of generating the error message,
> primarily sprintf()-type stuff.  The cost of scanning a multi-megabyte
> string seems likely to be much larger.
True. I ignored that there doesn't have to be an xid assigned yet... I still 
think its not very relevant though.

Andres
-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services