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.
Here is a new (final?) patch that adds the extra signature and for good measure includes the minor changes to varlena.c necessary to turn on slicing behaviour for left() and starts_with() (text_substring() already slices by default, just to no avail without this patch)
P.
|
compressed-datum-slicing-20190313a.patch
Description: Binary data
