On 2014-12-25 21:12:54 +0900, Michael Paquier wrote: > 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
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
