> On Mar 18, 2019, at 7:34 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Mar 18, 2019 at 10:14 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >> Stephen Frost <sfr...@snowman.net> writes: >>> * Andres Freund (and...@anarazel.de) wrote: >>>> I don't think that should stop us from breaking the API. You've got to >>>> do quite low level stuff to need pglz directly, in which case such an >>>> API change should be the least of your problems between major versions. >> >>> Agreed, this is across a major version and I don't think it's an issue >>> to break the API. >> >> Yeah. We don't normally hesitate to change internal APIs across major >> versions, as long as >> (a) the breakage will be obvious when recompiling an extension, and >> (b) it will be clear how to get the same behavior as before. >> >> Adding an argument qualifies on both counts. Sometimes, if a very >> large number of call sites would be affected, it makes sense to use >> a wrapper function so that we don't have to touch so many places; >> but that doesn't apply here. > > +1. I think Paul had it right originally.
In that spirit, here is a “one pglz_decompress function, new parameter” version for commit. Thanks! P
compressed-datum-slicing-20190318a.patch
Description: Binary data
