(adding -hackers back into thread, got dropped by my email client, sorry) On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Mat Arye <m...@timescaledb.com> writes: > > I tried looking in the contrib modules and didn't find many with lots of > > planner hook usage. > > I'm not really sure why planner hooks would have anything to do with your > exposed SQL API? > Sorry what I meant was i'd like to package different versions of my extension -- both .sql and .c -- and have the extension act consistently for any version until I do a ALTER EXTENSION UPDATE. So, I'd prefer a DB with an older extension to have the logic/code in the hook not change even if I install a newer version's .so for use in another database (but don't update the extension to the newer version). Does that make any sense? > > You will need to have separate builds of your extension for each PG > release branch you work with; we force that through PG_MODULE_MAGIC > whether you like it or not. But that doesn't translate to needing > different names for the library .so files. Generally people either > mantain separate source code per-branch (just as the core code does) > or put in a lot of #ifs testing CATALOG_VERSION_NO to see which > generation of PG they're compiling against. > Yeah we plan to use different branches for different PG versions. > > regards, tom lane >
