Re: Support for 8-byte TOAST values, round two

On Mon, Sep 14, 2026 at 07:24:34AM +0545, Oleg Bartunov wrote:
> Just to make sure I understand the intended abstraction correctly:
> with this patch, should I think of VARATT_IS_EXTERNAL_ONDISK() as
> identifying a family of on-disk external representations, while the
> vartag identifies the concrete physical representation within that
> family? In other words: VARATT_IS_EXTERNAL_ONDISK() ->
> representation family, and VARTAG_* -> concrete representation If
> so, that is actually the distinction I was looking for.

(Perhaps avoid html..)

In this context, VARATT_IS_EXTERNAL_ONDISK() still means "Is this
varlena an on-disk external TOAST pointer?", it just means that it
englobes *both* varatt_external_oid and varatt_external_oid8.

I was surprised to see that we can rely on EXTERNAL_ONDISK() heavily
in the core code once we have the second external on-disk vartag, and
more surprised that we don't really need a set of macros of the type
EXTERNAL_ONDISK_OID() or EXTERNAL_ONDISK_OID8() with the changes in
detoast.h suggested by Bharath. We could add these types of macros,
of course, but it's just bloating more varatt.h with stuff we don't
need at the end, at least when it comes to the core code and what I've
seen outside of core in the open. This last remark may not apply to
fancier outsider cases out there I am not aware of.
--
Michael