On Thu, Dec 25, 2014 at 7:48 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
