From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, suchithjn22(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: The documentation for storage type 'plain' actually allows single byte header |
Date: | 2023-09-29 22:45:52 |
Message-ID: | 1421365.1696027552@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Fri, 2023-09-29 at 18:19 -0400, Bruce Momjian wrote:
>> Where did we end with this? Is a doc patch the solution?
> I don't think this went anywhere, and a doc patch is not the solution.
> Tom has argued convincingly that single-byte headers are an effect of the TOAST
> system, and that STORAGE PLAIN should disable all effects of TOAST.
Well, that was the original idea: you could use STORAGE PLAIN if you
had C code that wasn't yet toast-aware. However, given the lack of
complaints, it seems there's no non-toast-aware code left anywhere.
And that's not too surprising, because the evolutionary pressure to
fix such code would be mighty strong, and a lot of time has passed.
I'm now inclined to think that changing the docs is better than
changing the code; we'd be more likely to create new problems than
fix anything useful.
I wonder though if there's really just one place claiming that
that's how it works. A trawl through the code comments might
be advisable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gulyás Attila | 2023-09-30 00:02:41 | Re: `pg_restore --if-exists` clarification |
Previous Message | Laurenz Albe | 2023-09-29 22:35:00 | Re: The documentation for storage type 'plain' actually allows single byte header |
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2023-09-29 22:50:11 | Re: SHARED locks barging behaviour |
Previous Message | Laurenz Albe | 2023-09-29 22:39:43 | Re: document the need to analyze partitioned tables |