Re: Add %z support to elog/ereport?
От | Tom Lane |
---|---|
Тема | Re: Add %z support to elog/ereport? |
Дата | |
Msg-id | 30626.1390008962@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add %z support to elog/ereport? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add %z support to elog/ereport?
|
Список | pgsql-hackers |
I wrote: > Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: