Hi, Thank you all for the reviews and discussion!
On the strictness question raised by Greg — I agree with Andres here. These functions are meant for inspecting tid values that already exist, so rejecting "impossible" values like (-1,0) would not be providing any real benefit. I believe the tid input function is the appropriate place for any validation, and these assessors should just faithfully report what's in the datum. Regards, Ayush On Mon, 9 Mar 2026 at 19:32, Andres Freund <[email protected]> wrote: > Hi, > > On 2026-03-09 09:34:46 -0400, Greg Sabino Mullane wrote: > > On Sun, Mar 8, 2026 at 3:31 PM Tomas Vondra <[email protected]> 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 >
