Re: tid_blockno() and tid_offset() accessor functions
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Greg Sabino Mullane <htamfids@gmail.com>
Cc: Tomas Vondra <tomas@vondra.me>, Alexandre Felipe <o.alexandre.felipe@gmail.com>,
Ayush Tiwari <ayushtiwari.slg01@gmail.com>, pgsql-hackers@postgresql.org
Date: 2026-03-09T14:01:53Z
Lists: pgsql-hackers
Hi, On 2026-03-09 09:34:46 -0400, Greg Sabino Mullane wrote: > On Sun, Mar 8, 2026 at 3:31 PM Tomas Vondra <tomas@vondra.me> wrote: > > > No opinion. For displaying the bogus TID value (like "(-1,0)") it's > > probably OK to show values that are a bit weird. If anything, we should > > be more careful on input, it's too late for tid_block() to decide what to > > do with an "impossible" TID value. > > > > This one doesn't sit right with me. I think it's not too late. No reason > why tid_block cannot be stricter here than tid itself and complain. Other > than that, the patch looks good to me. I don't see any advantage in that. These functions are useful for inspecting tid values that come from some source. When would you *ever* gain *anything* from not being able to see the block / offset of a tid datum that you already have? This isn't an end user focused type / set of accessor functions were being particularly careful about input validation will perhaps prevent users from making mistakes... Greetings, Andres Freund
Commits
-
Add tid_block() and tid_offset() accessor functions
- df6949ccf7a6 19 (unreleased) landed