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

On Mon, Sep 21, 2026 at 03:39:23PM -0700, Bharath Rupireddy wrote:
> On Mon, Sep 21, 2026 at 4:11 AM John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
>> It looks like doc/src/sgml/limits.sgml needs to be updated as well.
>
> Nice catch. Thanks for pointing it out. Please find the attached patch for that.

Yeah, I've missed a spot that required a refresh.

> I also attached the 0001 and 0002 from
> https://www.postgresql.org/message-id/CALj2ACUmBhBGb%2B4d8SRq9JT\_ZsObCAvY6-10CKgSWX98zdv2DQ%40mail.gmail.com
> here as 0002 and 0003.

Not feeling much about 0002 at this stage. I don't disagree about the
fact of documenting something, but one has a few more ways to do it,
one being a CTAS with a WITH clause. You could also drop the varlena
attributes from a definition (after having migrated the values),
VACUUM FULL to drop the existing TOAST and add a new text attribute to
force the creation of a new TOAST table based on the new type wanted,
after an ALTER TABLE SET.

> In the attached 0003, I fixed an issue with the remote version check
> and simplified the tests by reusing an existing table whose reloption
> is already reset, and verifying that the dump reports the original
> TOAST type. This is good enough to cover the new code without starting
> a new instance just to test this. I also used a join instead of a
> per-relation lookup in the query to get the TOAST type, which avoids
> an extra catalog lookup for every table.

I still don't think much about this part, FWIW. That's just switching
some semantics to a different one which shows unclear benefits (aka it
is about what we should do on the dump side if we find a reloption set
or not, vs what's stored on disk).
--
Michael