Re: CurrentExtensionObject was Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?
On Thu, Dec 31, 2015 at 04:41:44PM -0500, Chapman Flack wrote: > I suppose there really won't be a way to do this with reliability > unless someday extensions can hook the dependency infrastructure, > as you mentioned in passing in an earlier message. > > That sounds like a longer discussion. But I wondered if it might > not be too hard to put PGDLLIMPORT on CurrentExtensionObject as > a stopgap. > > ... though perhaps it doesn't matter that much, because I still > have to write a circuitous workaround anyway, and keep it in the > code until 9.1 through 9.4 all vanish from the earth. I think we decided that only older _minor_ versions would need your workaround, so anyone doing a minor upgrade after 9.5.1 and friends would be fine. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: CurrentExtensionObject was Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?
On 12/31/15 16:13, Tom Lane wrote:
>> I see that 9.5.0 already adds PGDLLIMPORT on the global variable
>> creating_extension, but CurrentExtensionObject on the very next
>> line of extension.h still doesn't have it.
>
> Why would you need to access that?
This returns to the earlier question about extensions whose purpose
is to enable other extensions. I'm thinking a bit ahead. At the moment,
I am only working on nudging PL/Java itself into the extension framework,
so you can install *it* with CREATE EXTENSION. For that, I can get along
without the extension Oid.
Down the road, it would be quite natural for PL/Java users to develop
functionality in Java, package it in a jar file, and want to install that
using CREATE EXTENSION. So they'd distribute their foo.jar file with a
foo.control file (requires = 'pljava'), and a very short foo--1.0.0.sql file
SELECT sqlj.install_jar('file:foo.jar', 'foo', true);
and most of the right stuff will automagically happen ... the
associated system objects (created by the deployment script inside
the jar, executed by install_jar) will be captured as extension
members. But the jar itself, stashed by install_jar into a PL/Java
managed table that can't participate in pg_depend, somehow still
needs to be associated with the extension too.
I suppose there really won't be a way to do this with reliability
unless someday extensions can hook the dependency infrastructure,
as you mentioned in passing in an earlier message.
That sounds like a longer discussion. But I wondered if it might
not be too hard to put PGDLLIMPORT on CurrentExtensionObject as
a stopgap.
... though perhaps it doesn't matter that much, because I still
have to write a circuitous workaround anyway, and keep it in the
code until 9.1 through 9.4 all vanish from the earth.
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: CurrentExtensionObject was Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?
Chapman Flack writes: > I see that 9.5.0 already adds PGDLLIMPORT on the global variable > creating_extension, but CurrentExtensionObject on the very next > line of extension.h still doesn't have it. Why would you need to access that? 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
CurrentExtensionObject was Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?
While on the subject of things that could make it or not into 9.5.?, I see that 9.5.0 already adds PGDLLIMPORT on the global variable creating_extension, but CurrentExtensionObject on the very next line of extension.h still doesn't have it. The simplest way I've come up with in Windows to identify the extension being created is to create some temporary object, call getExtensionOfObject() on it, then drop it. A bit circuitous when on any other platform I can just look at CurrentExtensionObject -Chap -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
