On Sep 14, 2026 05:02, Michael Paquier <michael@paquier.xyz> wrote:

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

Thanks, that makes sense. I had missed that the varatt_external rename turns this particular case into a compile-time failure.

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

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.

Oleg

--
Michael