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

On Tue, Sep 15, 2026 at 01:05:09PM -0400, Greg Burd wrote:
> Pinning default_toast_compression in the test would work too, though it costs
> you the coverage of whichever method you did not pin.

Using default_toast_compression is perhaps nicer (same as
portals.sql). It offers more predictibility in the output and we
don't really care about the compression method in this case. The md5
computations can be more expensive, which I find annoying, so I'm
eager to just reuse the smart pattern of toast.sql instead. It's much
cheaper, and enforces the out-of-line behavior we want here.

Note: test_decoding has the same issue. Oops. Will fix in a bit
after more checks.

> Either way this is Michael's call to make, I'm anxious to hear his thoughts
> on this.

Replied to that upthread, as of:
https://www.postgresql.org/message-id/aqni9bvWV0UIUEZy@paquier.xyz

I don't think that this new reloption should equal in expectations
with fillfactor and/or tuple_toast_target.
--
Michael