| 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
| 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 |