| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Subject: | Re: Support for XLogRecPtr in expand_fmt_string? |
| Date: | 2012-07-06 22:03:19 |
| Message-ID: | 1341612199.7092.36.camel@vanquo.pezone.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On tis, 2012-07-03 at 14:52 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Farina | 2012-07-06 22:41:41 | Re: Bug tracker tool we need |
| Previous Message | Peter Eisentraut | 2012-07-06 21:46:03 | Re: transforms |