From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add %z support to elog/ereport? |
Date: | 2014-01-18 01:36:02 |
Message-ID: | 30626.1390008962@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-18 02:01:01 | Re: Minor improvements to sslinfo contrib module |
Previous Message | Tom Lane | 2014-01-18 01:23:27 | Re: Add %z support to elog/ereport? |