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
