On Wed, Jun 13, 2012 at 11:06 AM, Andres Freund <and...@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 <t...@sss.pgh.pa.us> wrote: >> > Robert Haas <robertmh...@gmail.com> writes: >> >> On Tue, Jun 12, 2012 at 9:52 PM, Tom Lane <t...@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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
