> On Mar 13, 2019, at 3:09 AM, Tomas Vondra <tomas.von...@2ndquadrant.com>
> wrote:
>
> On 3/13/19 3:19 AM, Michael Paquier wrote:
>> On Tue, Mar 12, 2019 at 07:01:17PM -0700, Andres Freund wrote:
>>> I don't think this is even close to popular enough to incur the
>>> maybe of a separate function / more complicated interface. By this
>>> logic we can change basically no APIs anymore.
>>
>> Well, if folks here think that it is not worth worrying about, I won't
>> cry on that either. If only the original API is kept, could it just
>> be possible to make it extensible with some bits16 flags then? Adding
>> only a boolean is not really appealing.
>
> In my experience "extensible" APIs with bitmasks are terrible - it's a
> PITA to both use them and maintain stuff that calls them. That is not to
> say there is no use for that design pattern, or that I like API breaks.
> But I very much prefer when an API change breaks things, alerting me of
> places that may require attention.
>
> And I'm with Andres here about the complexity being rather unwarranted
> here - I don't think we've changed pglz API in years (if ever), so what
> is the chance we'd actually benefit from the extensibility soon?
I’m just going to saw the baby in half, retaining the old pglz_decompress()
signature and call into a pglz_decompress_checked() signature that allows one
to optionally turn off the checking at the end (which is all the split boolean
argument does, so probably my current name is not the best name for that
argument).
Scream madly at me if you consider this inappropriate.
P
