Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2012-06-13T16:00:43Z
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 Wed, Jun 13, 2012 at 11:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@2ndquadrant.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