| 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-21 10:30:14 |
| Message-ID: | CAGEoWWRtV82uB9uraC6B8++=JTShRSnQFTSnK2WDrnpQEpyqrQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 21, 2021 at 3:53 PM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 2021-01-20 08:50, Ashutosh Bapat wrote:
> > 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.
>
> Then you'd end up with half the code doing this and half the code doing
> that. That doesn't sound very attractive. It's not like "%X/%X" is
> hard to type.
>
:). That's true. I thought LSN_FORMAT would document the string
representation of an LSN. But anyway I am fine with this as well.
>
> --
> Peter Eisentraut
> 2ndQuadrant, an EDB company
> https://www.2ndquadrant.com/
>
--
--
Best Wishes,
Ashutosh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2021-01-21 11:11:55 | Re: PoC/WIP: Extended statistics on expressions |
| Previous Message | Peter Eisentraut | 2021-01-21 10:23:16 | Re: Printing LSN made easy |