From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(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? |
Date: | 2014-01-21 15:11:23 |
Message-ID: | 20140121151123.GH10723@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas escribió:
> On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I wrote:
> >> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> >>> On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
> >>> Am I just too tired, or am I not getting how INT64_FORMAT currently
> >>> allows the arguments to be used posititional?
> >
> >> It doesn't, which is one of the reasons for not allowing it in
> >> translatable strings (the other being lack of standardization of the
> >> strings that would be subject to translation).
> >
> > On second thought, that answer was too glib. There's no need for %n$
> > in the format strings *in the source code*, so INT64_FORMAT isn't getting
> > in the way from that perspective. However, expand_fmt_string() is
> > necessarily applied to formats *after* they've been through gettext(),
> > so it has to expect that it might see %n$ in the now-translated strings.
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.
> Perhaps we should jettison entirely the idea of using the operating
> system's built-in sprintf and use one of our own that has all of the
> nice widgets we need, like a format code that's guaranteed to be right
> for uint64 and one that's guaranteed to be right for Size. This could
> turn out to be a bad idea if the best sprintf we can write is much
> slower than the native sprintf on any common platforms ... and maybe
> it wouldn't play nice with GCC's desire to check format strings. But
> what we're doing now is a real nuisance, too.
Maybe we can use our own implementation if the system's doesn't support
%z. It's present in glibc 2.1 at least, and it's part of in the 2004
edition of POSIX:2001.
http://pubs.opengroup.org/onlinepubs/009695399/functions/sprintf.html
(It is not present in SUSv2 (1997), and I wasn't able to find the
original POSIX:2001 version.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-01-21 15:16:45 | Re: Add %z support to elog/ereport? |
Previous Message | Robert Haas | 2014-01-21 15:03:28 | Re: [patch] Potential relcache leak in get_object_address_attribute |