I wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
>> On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
>>> I think this approach is fundamentally broken, because it can't reasonably
>>> cope with any case more complicated than "%zu" or "%zd".
>> 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.
It's still the case that we need a policy against INT64_FORMAT in
translatable strings, though, because what's passed to the gettext
mechanism has to be a fixed string not something with platform
dependencies in it. Or so I would assume, anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
