From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add %z support to elog/ereport? |
Date: | 2013-11-11 20:36:56 |
Message-ID: | 12958.1384202216@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-11-11 12:31:55 -0500, Robert Haas wrote:
>> I seem to recall that our %m support involves rewriting the error
>> string twice, which I think is actually kind of expensive if, for
>> example, you've got a loop around a PL/pgsql EXCEPTION block.
> Yes, it does that. Is that actually where a significant amount of time
> is spent? I have a somewhat hard time believing that.
I don't see any double copying. There is *one* copy made by
expand_fmt_string. Like Andres, I'd want to see proof that
expand_fmt_string is a significant time sink before we jump through
these kinds of hoops to get rid of it. It looks like a pretty cheap
loop to me. (It might be less cheap if we made it smart enough to
identify 'z' flags, though :-()
>> I'd
>> actually like to find a way to get rid of the existing %m support,
>> maybe by having a flag that says "oh, and by the way append the system
>> error to my format string"; or by changing %m to %s and having the
>> caller pass system_error_string() or similar for that format position.
The first of these doesn't work unless you require translations to
assemble the string the same way the English version does. The second
would work, I guess, but it'd sure be a pain to convert everything.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-11-11 20:39:45 | Re: MVCC snapshot timing |
Previous Message | Pavel Stehule | 2013-11-11 20:07:56 | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |