From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. |
Date: | 2012-06-13 15:18:22 |
Message-ID: | CA+TgmoacGLSNBGdg5Ju4KEBaV4MH4rioTmJpR3NgQZV-bQK58g@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:06 AM, Andres Freund <andres(at)2ndquadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> >> On Tue, Jun 12, 2012 at 9:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
Mind you, I'm not going to spend a lot of time crying into my beer if
it turns out that there's no other reasonable way to implement this,
but I do think that it's entirely appropriate to ask why it's not
possible to do better.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-13 15:22:11 | Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. |
Previous Message | Andres Freund | 2012-06-13 15:06:05 | Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-13 15:22:11 | Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. |
Previous Message | Florian Pflug | 2012-06-13 15:08:09 | Re: Ability to listen on two unix sockets |