Re: Add %z support to elog/ereport?

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

In response to

Responses

Browse pgsql-hackers by date

  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