Mat Arye <mat@timescaledb.com> writes:
> On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane <tgl@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.
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.
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