From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | ashutosh(dot)bapat(at)enterprisedb(dot)com |
Cc: | peter(dot)eisentraut(at)2ndquadrant(dot)com, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, craig(dot)ringer(at)enterprisedb(dot)com |
Subject: | Re: Printing LSN made easy |
Date: | 2021-02-19 01:54:05 |
Message-ID: | 20210219.105405.1679334280565385272.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 18 Feb 2021 18:51:37 +0530, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote in
> On Thu, Feb 18, 2021 at 6:19 PM Peter Eisentraut <
> peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> > Here is an updated patch that just introduces LSN_FORMAT_ARGS(). I
> > think the result is quite pleasant.
> >
>
> Thanks a lot Peter for producing this patch. I am fine with it. The way
> this is defined someone could write xyz = LSN_FORMAT_ARGS(lsn). But then
> they are misusing it so I won't care. Even my proposal had that problem.
As for the side effect by expressions as the parameter, unary
operators are seldom (or never) applied to LSN. I think there's no
need to fear about other (modifying) expressions, too.
As a double-checking, I checked that the patch covers all output by
'%X/%X' and " ?>> ?32)" that are handling LSNs, and there's no
mis-replacing of the source variables.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo NAGATA | 2021-02-19 02:01:26 | Re: Implementing Incremental View Maintenance |
Previous Message | Greg Nancarrow | 2021-02-19 01:25:56 | Re: Parallel INSERT (INTO ... SELECT ...) |