On Mon, Jul 24, 2017 at 6:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Mat Arye <m...@timescaledb.com> writes: > > On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> 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? > > The newer version's .so simply is not going to load into the older > version; we intentionally prevent that from happening. It's not necessary > anyway because versions do not share library directories. Therefore, > you can have foo.so for 9.5 in your 9.5 version's library directory, > and foo.so for 9.6 in your 9.6 version's library directory, and the > filesystem will keep them straight for you. It is not necessary to > call them foo-9.5.so and foo-9.6.so. > I meant the extension version not the PG version. Let me try to explain: If version 0.1.0 has optimization A in the planner hook, and 0.2.0 has optimization B, I'd like the property that even if I install foo-0.2.0.so (and also have foo-0.1.0.so) in the cluster, any database that has not done an ALTER EXTENSION UPDATE will still do A while any databases that have updated the extension will do B. I'd also like to avoid doing a bunch of if/else statements to make this happen. But that's the ideal, not sure if I can make this happen. > > As for the other point, the usual idea is that if you have a > SQL-accessible C function xyz() that needs to behave differently after an > extension version update, then you make the extension update script point > the SQL function to a different library entry point. If your 1.0 > extension version originally had > > CREATE FUNCTION xyz(...) RETURNS ... > LANGUAGE C AS 'MODULE_PATHNAME', 'xyz'; > > (note that the second part of the AS clause might have been implicit; > no matter), then your update script for version 1.1 could do > > CREATE OR REPLACE FUNCTION xyz(...) RETURNS ... > LANGUAGE C AS 'MODULE_PATHNAME', 'xyz_1_1'; > > Then in the 1.1 version of the C code, the xyz_1_1() C function provides > the new behavior, while the xyz() C function provides the old behavior, > or maybe just throws an error if you conclude it's impractical to emulate > the old behavior exactly. As I mentioned earlier, you can usually set > things up so that you can share much of the code between two such > functions. > Thanks for that explanation. It's clear now. > > The pgstattuple C function in contrib/pgstattuple is one example of > having changed a C function's behavior in this way over multiple versions. > > regards, tom lane >