Skip site navigation (1) Skip section navigation (2)

Re: Inline Extension

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inline Extension
Date: 2012-01-19 13:58:17
Message-ID: 4F182179.10700@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Brad EdigerDate: 2012-01-19 14:04:07
Subject:
Previous:From: Alvaro HerreraDate: 2012-01-19 13:33:46
Subject: Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group