On Tue, Mar 9, 2021 at 1:56 AM Robert Haas <robertmh...@gmail.com> wrote: > > With this design, we can support changing the compression method on a > column quite easily. It's just a hint, like the STORAGE parameter. It > has no bearing on what can be present in the table, but just controls > how new values are stored. It would be nice to have a way to force > anything compressed with the old method to be re-compressed with the > new method, but not having that doesn't preclude allowing the > parameter to be changed.
So you mean if we are not able to decompress the old data because the binary was not compiled with lz4 then don't give error and continue. I think that depends upon how we are going to support this option for example suppose we are setting as ALTER COLUMN f1 SET COMPRESSION pglz REWRITE, then maybe it make sense that even we are not able to rewrite because it was not compiled with lz4 we can successfully set the new compression method to pglz. Another thing is that if the table has some rowtype column then we will have to process that and decompress any compressed field inside that right? I haven't yet thought how complex it will be to decompress the data stored inside an already formed composite type but I will analyze this. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
