Re: Printing LSN made easy

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
Subject: Re: Printing LSN made easy
Date: 2021-01-20 07:50:11
Message-ID: CAGEoWWS0Qa0R20sjfU2zotTELrGZCEtBgiPO4116p0srbH1c_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 20, 2021 at 11:55 AM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 2020-11-27 11:40, Ashutosh Bapat wrote:
> > The solution seems to be simple though. In the attached patch, I have
> > added two macros
> > #define LSN_FORMAT "%X/%X"
> > #define LSN_FORMAT_ARG(lsn) (uint32) ((lsn) >> 32), (uint32) (lsn)
> >
> > which can be used instead.
>
> It looks like we are not getting any consensus on this approach. One
> reduced version I would consider is just the second part, so you'd write
> something like
>
> snprintf(lsnchar, sizeof(lsnchar), "%X/%X",
> LSN_FORMAT_ARGS(lsn));
>
> This would still reduce notational complexity quite a bit but avoid any
> funny business with the format strings.
>

Thanks for looking into this. I would like to keep both the LSN_FORMAT and
LSN_FORMAT_ARGS but with a note that the first can not be used in elog() or
in messages which require localization. We have many other places doing
snprintf() and such stuff, which can use LSN_FORMAT. If we do so, the
functions to output string representation will not be needed so they can be
removed.

--
Best Wishes,
Ashutosh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Wesley Aptekar-Cassels 2021-01-20 08:02:16 Getting column names/types from select query?
Previous Message Peter Eisentraut 2021-01-20 07:48:15 Re: Discarding DISCARD ALL