Re: Add %z support to elog/ereport? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add %z support to elog/ereport?
Date
Msg-id 12958.1384202216@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add %z support to elog/ereport?  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Next
From: Kevin Grittner
Date:
Subject: subquery q2 does not have attribute 0