|From:||Andres Freund <andres(at)2ndquadrant(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Add %z support to elog/ereport?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2014-01-21 11:33:40 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
> >> How difficult would it be to have expand_fmt_string deal with positional
> >> modifiers? I don't think we need anything from it other than the %n$
> >> notation, so perhaps it's not so problematic.
> > I don't think there's much reason to go there. I didn't go for the
> > pg-supplied sprintf() because I thought it'd be considered to
> > invasive. Since that's apparently not the case...
> Yeah, that would make expand_fmt_string considerably more complicated
> and so presumably slower. We don't really need that when we can make
> what I expect is a pretty trivial addition to snprintf.c. Also, fixing
> snprintf.c will make it safe to use the z flag in contexts other than
So, here's a patch adding %z support to port/snprintf.c including a
configure check to test whether we need to fall back. I am not too
happy about the runtime check as the test isn't all that meaningful, but
I couldn't think of anything better.
The second patch is a slightly updated version of a previously sent
version which is starting to use %z in some more places.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Robert Haas||2014-01-23 16:10:44||Re: dynamic shared memory and locks|
|Previous Message||Andrew Dunstan||2014-01-23 14:43:04||Re: commit fest 2014-01 week 1 report|