On Tue, Jan 20, 2026 at 03:45:12PM +0900, Michael Paquier wrote:
> What I am pretty sure about at this stage is that there is little love
> for the patch set I have sent on the other thread where I have been
> using pointer redirections for the TOAST function calls with
> callbacks (perhaps I'll be able to apply some of the renaming patches
> anyway, nobody would scream at me for that), at least nobody has put a
> +1 on it or just ignored it, so this approach feels dead to me. What
> you are suggesting upthread, though, is a direction I'd like to dig
> into and this comes down to how I can unify what you want to do for
> zstd and what I want to do with Oid8. Perhaps that you are right and
> that it is just simpler to invest on an interface in the detoast code,
> but I still see that there is nothing done for the logical decoding or
> amcheck code paths, which is something my other patch is able to deal
> with transparently.
(Added Nikhil in CC.)
While looking at what could be achieved for this release, I have
hacked on a patch that removes the limitation of the GUC enum for
defailt_toast_compression, which is currently limited at 4 values due
to the two bits allocated in the varlenas, and finished with the
attached.
This relies on the concept of a compression method "registry", saved
in toast_compression.c, that includes 4 fields for each compression
method supported in TOAST:
- The attcompression attribute in catalogs, a char.
- The compression method name.
- The compression GUC enum value.
- The on-disk varlena value, now moved to varatt.h.
What do you think about this approach?
--
Michael
