On Thu, 14 Dec 2017 10:29:10 -0500 Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Dec 13, 2017 at 7:18 AM, Ildus Kurbangaliev > <i.kurbangal...@postgrespro.ru> wrote: > > Since we agreed on ALTER syntax, i want to clear things about > > CREATE. Should it be CREATE ACCESS METHOD .. TYPE СOMPRESSION or > > CREATE COMPRESSION METHOD? I like the access method approach, and it > > simplifies the code, but I'm just not sure a compression is an > > access method or not. > > +1 for ACCESS METHOD. An access method then. > > > Current implementation > > ---------------------- > > > > To avoid extra patches I also want to clear things about current > > implementation. Right now there are two tables, "pg_compression" and > > "pg_compression_opt". When compression method is linked to a column > > it creates a record in pg_compression_opt. This record's Oid is > > stored in the varlena. These Oids kept in first column so I can > > move them in pg_upgrade but in all other aspects they behave like > > usual Oids. Also it's easy to restore them. > > pg_compression_opt -> pg_attr_compression, maybe. > > > Compression options linked to a specific column. When tuple is > > moved between relations it will be decompressed. > > Can we do this only if the compression method isn't OK for the new > column? For example, if the old column is COMPRESS foo PRESERVE bar > and the new column is COMPRESS bar PRESERVE foo, we don't need to > force decompression in any case. Thanks, sounds right, i will add it to the patch. -- --- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com Russian Postgres Company
