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
-
Simplify printing of LSNs
- 6f6f284c7ee4 14.0 landed
-
Unwind some workarounds for lack of portable int64 format specifier
- 6a1cd8b9236d 13.0 cited