From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-docs@postgresql.org
Subject: Re: [HACKERS] "Extension" versus "module"
Date: Mon, 14 Feb 2011 17:17:48 +0100
Message-ID: <m2wrl2k2tv.fsf@2ndQuadrant.fr> (raw)
In-Reply-To: <20217.1297697118@sss.pgh.pa.us>
References: <25160.1297664305@sss.pgh.pa.us>
<87r5ba4z1x.fsf@2ndQuadrant.fr>
<20217.1297697118@sss.pgh.pa.us>
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Hmm ... but what of contrib "modules" that don't build shared libraries
> at all --- pgbench and pg_upgrade for example?
>
> I think "shared library" is a perfectly fine term for that kind of
> object, and we don't need an alias for it anyway.
In my view, if there's no script, that is no SQL object to install in a
database, then it's not an extension. I would think that we keep the
directory named contrib for them. Then, an extension can be implemented
partly with a module, coded in C, installed as a shared library.
Another concern has to do with PLs. We said that with the dependency
mechanism it would be good to have PLs be EXTENSIONs. But those are
core provided extensions, one of them installed by default.
If we make PLs extensions, we might also want to have CREATE LANGUAGE
either ERROR out or silently do the CREATE EXTENSION instead, meaning
that CREATE LANGUAGE behavior would depend on creating_extension.
Sounds like a crock but ensures compatibility.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: dimitri@2ndQuadrant.fr, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] "Extension" versus "module"
In-Reply-To: <m2wrl2k2tv.fsf@2ndQuadrant.fr>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox