Re: tid_blockno() and tid_offset() accessor functions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tid_blockno() and tid_offset() accessor functions
Date: 2026-03-09 14:01:53
Message-ID: zlf5j4xjiycgse4ufgoljw7klgiroauufaxcrl4gcmh2yxdiha@7eavicmyk2dd
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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(at)vondra(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2026-03-09 14:05:09 Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c)
Previous Message Greg Sabino Mullane 2026-03-09 13:46:45 Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch