On 07.07.2012 01:03, Peter Eisentraut wrote:
On tis, 2012-07-03 at 14:52 -0400, Tom Lane wrote:
Peter Eisentraut<pete...@gmx.net> writes:
On tis, 2012-07-03 at 19:35 +0200, Andres Freund wrote:
I wonder if we just should add a format code like %R or something similar as a
replacement for the %X/%X notion.
Maybe just print it as a single 64-bit value from now on.
That'd be problematic also, because of the lack of standardization of
the format code for uint64. We could write things like
"message... " UINT64_FORMAT " ...more message"
but I wonder how well the translation tools would work with that;
and anyway it would at least double the translation effort for
messages containing such things.
The existing uses of INT64_FORMAT and UINT64_FORMAT show how this is
done: You print the value in a temporary buffer and use %s in the final
string. It's not terribly pretty, but it's been done this way forever,
including in xlog code, so there shouldn't be a reason to hesitate about
the use for this particular case.
That's hardly any simpler than what we have now.
On 03.07.2012 21:09, Tom Lane wrote:
> Andres Freund<and...@2ndquadrant.com> writes:
>> I wonder if we just should add a format code like %R or something
similar as a
>> replacement for the %X/%X notion.
>
> Only if you can explain how to teach gcc what it means for elog argument
> match checking. %m is a special case in that it matches up with a
> longstanding glibc-ism that gcc knows about. Adding format codes of our
> own invention would be problematic.
One idea would be to use a macro, like this:
#define XLOGRECPTR_FMT_ARGS(recptr) (uint32) ((recptr) >> 32), (uint32)
(recptr)
elog(LOG, "current WAL location is %X/%X", XLOGRECPTR_FMT_ARGS(RecPtr));
One downside is that at first glance, that elog() looks broken, because
the number of arguments don't appear to match the format string.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
