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
signature.asc
Description: PGP signature
