On Mon, Sep 21, 2026 at 03:39:23PM -0700, Bharath Rupireddy wrote: > On Mon, Sep 21, 2026 at 4:11 AM John Naylor <[email protected]> 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
signature.asc
Description: PGP signature
