Re: Add pg_walinspect function with block info columns - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Add pg_walinspect function with block info columns
Date
Msg-id CAH2-WznQ67q62+twx729ZCFeFJ5GN0zLkyMEfsuad+XV9JFFLg@mail.gmail.com
Whole thread Raw
In response to Re: Add pg_walinspect function with block info columns  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Sun, Mar 26, 2023 at 8:41 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> > I'd still put the LSN data before the three OIDs for consistency with
> > the structures, though my opinion does not seem to count much..
>
> I agree with Michael on this point. Also, although it may not be
> significant for SQL, the rows are output in lsn order from the
> function.

I guess that it makes sense to have the LSN data first, but to have
the other columns after that. I certainly don't dislike that approach.

I just noticed is that "forkname" appears towards the end among
declared output parameters, even in Bharath's v6. I think that it
should be after "relblocknumber" instead, because it is conceptually
part of the "composite primary key", and so belongs right next to
"relblocknumber". I failed to mention this detail upthread, I think.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: gkokolatos@pm.me
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Michael Paquier
Date:
Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry