Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 21, 2017 at 4:17 PM, Mat Arye <mat@timescaledb.com> wrote:
>> (I
>> want to avoid having to keep backwards-compatibility for all functions in
>> future shared-libraries).
> Are you sure that's a good idea? It seems like swimming upstream
> against the design. I mean, instead of creating a dispatcher library
> that loads either v1 or v2, maybe you could just put it all in one
> library, add a "v1" or "v2" suffix to the actual function names where
> appropriate, and then set up the SQL definitions to call the correct
> one. I mean, it's the same thing, but with less chance of the dynamic
> loader ruining your day.
Worth noting also is that we have a fair amount of experience now with
handling API changes in contrib modules. It's worth looking through
the update histories of the contrib modules that have shipped multiple
versions to see how they dealt with such issues. As Robert suggests,
it's just not that hard; usually a few shim functions in the C code will
do the trick.
I'd also point out that while you may think you don't need to keep
backwards compatibility across versions, your users are probably
going to think differently. The amount of practical freedom you'd
gain here is probably not so much as you're hoping.
regards, tom lane