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

On Sun, Sep 13, 2026 at 10:07:27PM +0545, Oleg Bartunov wrote:
> I did a quick check of out-of-tree users and found at least two
> examples. PostGIS has code like this in ToastCacheGetGeometry():

postgis holds a direct reference to varatt_external in its
libpgcommon/lwgeom_cache.c, which is wanted to feed data to
ToastCacheArgument. As far as I can see, their change is not
complicated, upgrade ToastCacheArgument.valueid to be an Oid8, then,
instead of the direct use of varatt_external() switch to a
toast_external_data combined with a call of toast_external_info_get()
to make the switch transparent, so as the TOAST value, Oid or Oid8 can
be retrieved.

So it's not a complicated change, and as far as I can see it's mostly
a matter of two PG_VERSION_NUM blocks plus a few tests. Using
varatt_external in the code would lead to a compilation failure,
because it's now renamed varatt_external_oid, one will not see a
runtime failure. It's going to be hard to miss that something is
wrong in this case.

> MobilityDB carries the same pattern. So an OID8 datum can now pass
> VARATT_IS_EXTERNAL_ONDISK() and existing code can then interpret it
> using the old OID pointer layout.

EXTERNAL_ONDISK() means either of them.

> I noticed this because we have been experimenting with alternative
> physical representations of large varlena values and tracing which
> parts of the value lifecycle actually depend on a particular TOAST
> representation. OID8 turned out to be a useful real-world test of that
> boundary.

MobilityDB is carrying the same patterns because it uses a copy-paste
of the postgis code. Again, this uses directly varatt_external, which
would fail at compilation under PG20. It sounds to me that they just
update their code on a regular basis based on postgis, so it means
that sending only a patch to adjust postgis would be enough. I'm
happy to take some time to do that, it

> Perhaps we need to distinguish explicitly between "any on-disk
> external pointer" and "the old OID on-disk pointer", rather than
> changing the meaning of the existing predicate?

It seems to me that this difference already exists in the patch, due
to the rebranding of varatt_external.

Note that if somebody has the idea to use VARTAG_SIZE() to copy
external varlena pointers, then the change is transparent.
--
Michael