On Sun, 5 Nov 2017 17:34:23 -0500 Robert Haas <robertmh...@gmail.com> wrote:
> On Sun, Nov 5, 2017 at 2:22 PM, Oleg Bartunov <obartu...@gmail.com> > wrote: > >> IIRC there were some concerns about what happened with pg_upgrade, > >> with consuming precious toast bits, and a few other things. > > > > yes, pg_upgrade may be a problem. > > A basic problem here is that, as proposed, DROP COMPRESSION METHOD may > break your database irretrievably. If there's no data compressed > using the compression method you dropped, everything is cool - > otherwise everything is broken and there's no way to recover. The > only obvious alternative is to disallow DROP altogether (or make it > not really DROP). In the patch I use separate table for compresssion options (because each attribute can have additional options for compression). So basicly compressed attribute linked to compression options, not the compression method and this method can be safely dropped. So in the next version of the patch I can just unlink the options from compression methods and dropping compression method will not affect already compressed tuples. They still could be decompressed. -- --- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com Russian Postgres Company
