Re: Fwd: [HACKERS] Syncing sql extension versions with shared library versions

[Mat Arye]

On Mon, Jul 24, 2017 at 6:16 PM, Tom Lane  wrote:

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

Re: Fwd: [HACKERS] Syncing sql extension versions with shared library versions

[Tom Lane]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Fwd: [HACKERS] Syncing sql extension versions with shared library versions

[Mat Arye]

(adding -hackers back into thread, got dropped by my email client, sorry)

On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane  wrote:

> Mat Arye  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
>