On 08.01.2012 22:36, Dimitri Fontaine wrote:
> The extension mechanism we added in 9.1 is aimed at allowing a fully
> integrated contrib management, which was big enough a goal to preclude
> doing anything else in its first release.
Hooray!
> Now we have it and we can think some more about what features we want
> covered, and a pretty obvious one that's been left out is the ability to
> define and update an extension without resorting to file system support
> for those extensions that do not need a shared object library. We could
> have been calling that “SQL ONLY” extensions, but to simplify the
> grammar support I did use the “inline” keyword so there we go.
Frankly I don't see the point of this. If the extension is an
independent piece of (SQL) code, developed separately from an
application, with its own lifecycle, a .sql file seems like the best way
to distribute it. If it's not, ie. if it's an integral part of the
database schema, then why package it as an extension in the first place?
> Please find attached a WIP patch implementing that. Note that the main
> core benefit to integrating this feature is the ability to easily add
> regression tests for extension related features. Which is not done yet
> in the attached.
I'm not sure I buy that argument. These inline extensions are
sufficiently different from regular extensions that I think you'd need
to have regression tests for both kinds, anyway.
> I'm sending this quite soon because of the pg_dump support. When an
> extension is inline, we want to dump its content, as we currently do in
> the binary dump output. I had in mind that we could output a full
> CREATE EXTENSION INLINE script in between some dollar-quoting rather
> than adding each extension's object with a ALTER EXTENSION ... ADD line
> like what pg_upgrade compatibility is currently doing.
I thought the main point of extensions is that that they're not included
in pg_dump. Again, if the extension is an integral part of the database,
then it probably shouldn't be an extension in the first place.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
