MIME-Version: 1.0
References: 
 <CAJTYsWUzok2+mvSYkbVUwq_SWWg-GdHqCuYumN82AU97SjwjCA@mail.gmail.com>
 <CAJTYsWVK6rw++WU94=gFk5ZR5ZXhT3BYOFxhm6tT9xOGG-drnA@mail.gmail.com>
 <CAE8JnxMXxJBs+U5HKkOfLd66vQHZ14XREHcEh-7_p-osaccFmQ@mail.gmail.com>
 <57388743-e380-4145-8b77-86ed23b062de@vondra.me>
 <CAKAnmm+gW9J4hr38g0uSUsswAVq+=bUYSSXp9tZrMegLyWieOg@mail.gmail.com>
 <zlf5j4xjiycgse4ufgoljw7klgiroauufaxcrl4gcmh2yxdiha@7eavicmyk2dd>
In-Reply-To: <zlf5j4xjiycgse4ufgoljw7klgiroauufaxcrl4gcmh2yxdiha@7eavicmyk2dd>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Wed, 11 Mar 2026 19:20:01 +0530
Message-ID: 
 <CAJTYsWVt5-R_2j2Wy+i5d-tw67SQ9uGVmd_R+dP-PgsBgGRfkA@mail.gmail.com>
Subject: Re: tid_blockno() and tid_offset() accessor functions
To: Andres Freund <andres@anarazel.de>
Cc: Greg Sabino Mullane <htamfids@gmail.com>, Tomas Vondra <tomas@vondra.me>,
	Alexandre Felipe <o.alexandre.felipe@gmail.com>, pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="0000000000004a9e2f064cbfea45"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWVt5-R_2j2Wy%2Bi5d-tw67SQ9uGVmd_R%2BdP-PgsBgGRfkA%40mail.gmail.com>
Precedence: bulk

--0000000000004a9e2f064cbfea45
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Thank you all for the reviews and discussion!

On the strictness question raised by Greg =E2=80=94 I agree with Andres her=
e. 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 <andres@anarazel.de> wrote:

> Hi,
>
> On 2026-03-09 09:34:46 -0400, Greg Sabino Mullane wrote:
> > On Sun, Mar 8, 2026 at 3:31=E2=80=AFPM Tomas Vondra <tomas@vondra.me> w=
rote:
> >
> > > 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 shou=
ld
> > > be more careful on input, it's too late for tid_block() to decide wha=
t
> to
> > > do with an "impossible" TID value.
> > >
> >
> > This one doesn't sit right with me. I think it's not too late. No reaso=
n
> > why tid_block cannot be stricter here than tid itself and complain. Oth=
er
> > 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 bein=
g
> particularly careful about input validation will perhaps prevent users fr=
om
> making mistakes...
>
> Greetings,
>
> Andres Freund
>

--0000000000004a9e2f064cbfea45
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>Thank you all for the reviews and discussion!<b=
r><br>On the strictness question raised by Greg =E2=80=94 I agree with Andr=
es here. These functions are meant for inspecting tid values that already e=
xist, so rejecting &quot;impossible&quot; values like (-1,0) would not be p=
roviding any real benefit. I believe the tid input function is the appropri=
ate place for any validation, and these assessors should just faithfully re=
port what&#39;s in the datum.<br><br>Regards,<br>Ayush</div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Mon, 9 Mar 2026 at 19:32, Andres Freund &lt;<a href=3D"mailto:andres@a=
narazel.de">andres@anarazel.de</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">Hi,<br>
<br>
On 2026-03-09 09:34:46 -0400, Greg Sabino Mullane wrote:<br>
&gt; On Sun, Mar 8, 2026 at 3:31=E2=80=AFPM Tomas Vondra &lt;<a href=3D"mai=
lto:tomas@vondra.me" target=3D"_blank">tomas@vondra.me</a>&gt; wrote:<br>
&gt; <br>
&gt; &gt; No opinion. For displaying the bogus TID value (like &quot;(-1,0)=
&quot;) it&#39;s<br>
&gt; &gt; probably OK to show values that are a bit weird. If anything, we =
should<br>
&gt; &gt; be more careful on input, it&#39;s too late for tid_block() to de=
cide what to<br>
&gt; &gt; do with an &quot;impossible&quot; TID value.<br>
&gt; &gt;<br>
&gt; <br>
&gt; This one doesn&#39;t sit right with me. I think it&#39;s not too late.=
 No reason<br>
&gt; why tid_block cannot be stricter here than tid itself and complain. Ot=
her<br>
&gt; than that, the patch looks good to me.<br>
<br>
I don&#39;t see any advantage in that. These functions are useful for inspe=
cting<br>
tid values that come from some source. When would you *ever* gain *anything=
*<br>
from not being able to see the block / offset of a tid datum that you alrea=
dy<br>
have?<br>
<br>
This isn&#39;t an end user focused type / set of accessor functions were be=
ing<br>
particularly careful about input validation will perhaps prevent users from=
<br>
making mistakes...<br>
<br>
Greetings,<br>
<br>
Andres Freund<br>
</blockquote></div>

--0000000000004a9e2f064cbfea45--