Re: Add %z support to elog/ereport?

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-11-11 11:18:22 -0500, Tom Lane wrote:
>> I think you'll find that %m is a totally different animal, because it
>> doesn't involve consuming an argument position.

> I was thinking of just replacing '%z' by '%l', '%ll' or '%' as needed
> and not expand it inplace. That should deal with keeping the argument
> position and such.
> But that won't easily work if somebody specifies flags like padding :/

[ reads manual ] Oh, I see that actually z *is* a flag, so you'd be
talking about replacing it with a different flag, ie %zu -> %llu or
similar. Yes, in principle that could work, but you'd have to be
prepared to cope with other flags, field width/precision, n$, etc,
appearing first. Sounds a bit messy, and this code is probably a
hot spot, remembering what we found out about the cost of fooling
with log_line_prefix.

>> I'm less than sure that every version of gcc will recognize %z, either
>> ...

> It's been in recognized in 2.95 afaics, so I think we're good.

[ fires up old HPUX box ] Nope:

$ cat test.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char**argv)
{
char buf[256];
size_t x = 0;

sprintf(buf, "%zu", (int)x);

return 0;
}
$ gcc -O2 -Wall test.c
test.c: In function `main':
test.c:9: warning: unknown conversion type character `z' in format
test.c:9: warning: too many arguments for format
$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.3/specs
gcc version 2.95.3 20010315 (release)

We might be willing to toss 2.95 overboard by now, but we'd need to be
sure of exactly what the new minimum usable version is.

>> and what about the translation infrastructure?

> That I have no clue about yet.

Me either. 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.

regards, tom lane