Robert Haas escribió: > On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I wrote: > >> Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers