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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Date: 2012-06-13 16:00:43
Message-ID: CA+TgmoaprEKkBOBptC2CWB3uJ-+bH0UNgQdxvqsXg+sxUNO77w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Jun 13, 2012 at 11:55 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>> On Wednesday, June 13, 2012 05:18:22 PM Robert Haas wrote:
>>> 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.
>
> I don't think it's relevant either.  In the first place, I don't think
> that errors occurring "multi megabytes" into a JSON blob are going to
> occur often enough to be performance critical.  In the second place,
> removing cycles from the non-error case is worth something too, probably
> more than making the error case faster is worth.
>
> In any case, the proposed scheme for providing context requires that
> you know where the error is before you can identify the context.  I
> considered schemes that would keep track of the last N characters or
> line breaks in case one of them proved to be the one we need.  That
> would add enough cycles to non-error cases to almost certainly not be
> desirable.  I also considered trying to back up, but that doesn't look
> promising either for arbitrary multibyte encodings.

Oh, I see. :-(

Well, I guess I'll have to suck it up, then.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2012-06-13 16:19:31 pgsql: In pg_upgrade, verify that the install user has the same oid on
Previous Message Tom Lane 2012-06-13 15:55:40 Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-06-13 16:03:14 Re: [PATCH 16/16] current version of the design document
Previous Message Robert Haas 2012-06-13 15:59:27 Re: 9.3devel branch