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