В письме от пятница, 20 мая 2022 г. 23:17:42 MSK пользователь Stephen Frost написал:
> While I generally agree that we want to provide extensibility in this > area, given that we already have zstd as a compile-time option and it > exists in other parts of the system, I don't think it makes sense to > require users to install an extension to use it. I mean that there can be Compression Method Provider, either built in postgres core, or implemented in extension. And one will need to create Compression method using desired Compression Method Provider. Like (it is just pure imagination) CREATE COMPRESSION METHOD MY_COMPRESSION USING 'my_compression_provider'; This will assign certain bits combination to that method, and later one can use that method for TOAST compression... > > Moreover I guess this API (may be with some modification) can be used for > > seamless data encryption, for example. > > Perhaps.. but this kind of encryption wouldn't allow indexing Yes, this will require some more efforts. But for encrypting pure storage that API can be quite useful. > and certainly lots of other metadata would still be unencrypted (the entire > system catalog being a good example..). In many it is enough to encrypt only sensible information itself, not whole metadata. My point was not to discuss DB encryption, it is quite complex issue, my point was to point out that API that allows custom compression methods may became useful for other solutions. Encryption was just first example that came in my mind. Robert Haas has another example for compression method optimized for certain data type. So it is good if you can have method of your own. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su
signature.asc
Description: This is a digitally signed message part.
