Re: tid_blockno() and tid_offset() accessor functions

Hello,

Attaching a V2-patch post rebasing due to oid conflict with the latest main
branch. In addition to that changing the sql function name for tid block
number to tid_block and adding document related changes.

Please review and let me know your thoughts.

Regards,
Ayush

On Sat, 28 Feb 2026 at 00:29, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

> Hi hackers,
>
> As of now we don't have any built-in way to extract the block and offset
> components from a TID. When people need to group by page (like for bloat
> analysis) or filter by specific blocks, they usually end up using the
> `ctid::text::point` hack:
>
> SELECT (ctid::text::point)[0]::bigint AS blockno,
> (ctid::text::point)[1]::int AS offset
> FROM my_table;
>
> This works, but it's pretty clunky, relies on the text representation, and
> isn't great if you're trying to parse TIDs outside of SQL.
>
> The attached patch adds two simple accessor functions:
> - `tid_blockno(tid) -> bigint`
> - `tid_offset(tid) -> integer`
>
> A couple of quick notes on the implementation I went for:
> - `tid_blockno` returns `int8` since `BlockNumber` is `uint32` and could
> overflow `int4`.
> - `tid_offset` returns `int4` since `OffsetNumber` is `uint16`.
> - Both are marked leakproof and strict.
> - I used the `NoCheck` macros from `itemptr.h` so they safely handle
> user-supplied literals like `(0,0)`.
>
> Please let me know what you think!
>
> Regards,
> Ayush
>