Re: Add %z support to elog/ereport?

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Add %z support to elog/ereport?
Дата
Msg-id 20140121151123.GH10723@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Add %z support to elog/ereport?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Add %z support to elog/ereport?  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Robert Haas escribió:
> On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I wrote:
> >> Andres Freund <andres@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [patch] Potential relcache leak in get_object_address_attribute
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Add %z support to elog/ereport?