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