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)
