public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ayush Tiwari <[email protected]>
To: Andres Freund <[email protected]>
Cc: Greg Sabino Mullane <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Alexandre Felipe <[email protected]>
Cc: [email protected]
Subject: Re: tid_blockno() and tid_offset() accessor functions
Date: Wed, 11 Mar 2026 19:20:01 +0530
Message-ID: <CAJTYsWVt5-R_2j2Wy+i5d-tw67SQ9uGVmd_R+dP-PgsBgGRfkA@mail.gmail.com> (raw)
In-Reply-To: <zlf5j4xjiycgse4ufgoljw7klgiroauufaxcrl4gcmh2yxdiha@7eavicmyk2dd>
References: <CAJTYsWUzok2+mvSYkbVUwq_SWWg-GdHqCuYumN82AU97SjwjCA@mail.gmail.com>
<CAJTYsWVK6rw++WU94=gFk5ZR5ZXhT3BYOFxhm6tT9xOGG-drnA@mail.gmail.com>
<CAE8JnxMXxJBs+U5HKkOfLd66vQHZ14XREHcEh-7_p-osaccFmQ@mail.gmail.com>
<[email protected]>
<CAKAnmm+gW9J4hr38g0uSUsswAVq+=bUYSSXp9tZrMegLyWieOg@mail.gmail.com>
<zlf5j4xjiycgse4ufgoljw7klgiroauufaxcrl4gcmh2yxdiha@7eavicmyk2dd>
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
>
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: tid_blockno() and tid_offset() accessor functions
In-Reply-To: <CAJTYsWVt5-R_2j2Wy+i5d-tw67SQ9uGVmd_R+dP-PgsBgGRfkA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox