(adding -hackers back into thread, got dropped by my email client, sorry)
On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Mat Arye <mat@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.
