Re: Printing LSN made easy

Craig Ringer <craig.ringer@enterprisedb.com>

From: Craig Ringer <craig.ringer@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2020-11-30T02:12:35Z
Lists: pgsql-hackers
On Mon, Nov 30, 2020 at 1:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Michael Paquier <michael@paquier.xyz> writes:
> > On Fri, Nov 27, 2020 at 04:10:27PM +0530, Ashutosh Bapat wrote:
> >> Off list Craig Ringer suggested introducing a new format specifier
> >> similar to %m for LSN but I did not get time to take a look at the
> >> relevant code. AFAIU it's available only to elog/ereport, so may not
> >> be useful generally. But teaching printf variants about the new format
> >> would be the best solution. However, I didn't find any way to do that.
>
> > -1.  %m maps to errno, that is much more generic.  A set of macros
> > that maps to our internal format would be fine enough IMO.
>
> Agreed.  snprintf.c is meant to implement a recognized standard
> (ok, %m is a GNU extension, but it's still pretty standard).
> I'm not on board with putting PG-only extensions in there.
>

Fair enough. I did not realise that %m was a GNU extension (never looked
closely) so I thought we had precedent for Pg specific extensions there.

Agreed in that case, no argument from me.

Commits

  1. Simplify printing of LSNs

  2. Unwind some workarounds for lack of portable int64 format specifier