On 2013-12-06 09:54:59 -0500, Peter Eisentraut wrote:
> On 11/11/13, 12:01 PM, Tom Lane wrote:
> > I do recall Peter saying that the infrastructure knows how to
> > verify conversion specs in translated strings, so it would have to be
> > aware of 'z' flags for this to work.
>
> It just checks that the same conversion placeholders appear in the
> translation. It doesn't interpret the actual placeholders. I don't
> think this will be a problem.
Ok, so here's a patch.
Patch 01 introduces infrastructure, and elog.c implementation.
Patch 02 converts some elog/ereport() callers to using the z modifier,
some were wrong at least on 64 bit windows.
In patch 01, I've modified configure to not define [U]INT64_FORMAT
directly, but rather just define INT64_LENGTH_MODIFIER as
appropriate. The formats are now defined in c.h.
INT64_LENGTH_MODIFIER is defined without quotes - I am not sure whether
that was the right choice, it requires using CppAsString2() in some
places. Maybe I should just have defined it with quotes instead. Happy
to rejigger it if somebody thinks the other way would be better.
Note that I have decided to only support the z modifier properly if no
further modifiers (precision, width) are present. That seems sufficient
for now, given the usecases, and more complete support seems to be
potentially expensive without much use.
I wonder if we should also introduce SIZE_T_FORMAT and SSIZE_T_FORMAT,
there's some places that have #ifdef _WIN64 guards and similar that look
like they could be simplified.
Btw, walsender.c/walreceiver.c upcast an int into an unsigned long for
printing? That's a bit strange.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services