On Tue, Mar 21, 2023 at 11:33 PM Michael Paquier <mich...@paquier.xyz> wrote: > > The new pg_get_wal_block_info outputs columns in an order that doesn't > > seem like the most useful possible order to me. This gives us another > > reason to have separate GetWALRecordInfo and GetWALBlockInfo utility > > functions rather than sharing logic for building output tuples. > > > > Specifically, I think that pg_get_wal_block_info should ouput the > > "primary key" columns first: > > > > reltablespace, reldatabase, relfilenode, blockid, start_lsn, end_lsn > > It seems to me that this is up to the one using this SQL?
If you see it that way, then why does it matter what I may want to do with the declared order? > I am not > sure to follow why this is important. For the cases you have poked > at, I guess it is, but is strikes me that it is just natural to shape > that to match the C structures we use for the WAL records > themselves, so the other way around. I don't feel very strongly about it, but it seems better to highlight the difference that exists between this and pg_get_wal_records_info. > Hence, it seems to me that 0002 has the order pretty much right. > What's the point in adding the description, by the way? Only > consistency with the other function? Is that really useful if you > want to apply more quals when retrieving some block data? I don't understand. It's useful to include the description for the same reason as it's useful to include it in pg_get_wal_records_info. Why wouldn't it be useful? Most individual records that have any block_ref blocks have exactly one. Most individual WAL records are very simple record types. So pg_get_wal_block_info just isn't going to look that different to pg_get_wal_records_info, once they share most of the same columns. The way that pg_get_wal_block_info disaggregates on block won't make the output look all that different. So each distinct "description" will usually only appear once in pg_get_wal_block_info anyway. -- Peter Geoghegan
