Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
