On 2014-12-25 21:12:54 +0900, Michael Paquier wrote:
> On Thu, Dec 25, 2014 at 7:48 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > I think it's a bad idea to move it away - the current placement provides
> > a API that allows to get at the image data without having to deal with
> > the low level details. E.g. the in_use, has_image and hole
> > logic. *Especially* when we add compression that's quite a useful
> > abstraction. Having it it in place allows us to restructure internals
> > without disturbing clients - and i don't see any price in this case.
>
> There is no price as long as we keep the compression algorithm fixed
> in core, but I do foresee one regarding the pluggability of the
> decompression API knowing that RestoreBlockImage is the natural place
> where block decompression should occur, and that now it is shared
> between frontend and backend layers.
> I am digressing here, but what I had in mind was to add exactly there
> a hook to allow our users to plugin a custom compression algorithm,
> something that could be useful for us and for our users in terms of
> flexibility for the WAL compression, particularly for algorithms that
> are not compatible with the Postgres license. -- Michael
I personally think that's a bad idea and we shouldn't provide
functionality for that. But even if we added it, something that provides
the decompression for frontend code seems critical.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
