Re: Dumping an Extension's Script

So,

Lots of things are being said, most of them are really interesting and
some of them are just re-hashing what we said about a year ago in the
"Inline Extensions" thread, whose conclusion was that the key not to
have two different beasts (inline, file based) was for pg_dump to
process them all the same way.

Meanwhile, I think I need to address that reaction first:

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> What I can't quite figure out is - AIUI, extensions are a way of
> bundling shared libraries with SQL scripts, and a way of managing the
> dump and restore process.

Not quite.

Extensions are user defined CASCADE support.

It's all about pg_depend extensibility.

Extensions are a way to manage dependencies of SQL objects in a way that
allow you to manage them as a single entity. Now you can

CREATE EXTENSION
ALTER EXTENSION
DROP EXTENSION

and all you're doing is managing a bunch of SQL objects at once.

The fact that it allows to implement a working dump&restore of aborigen
extensions called contribs has been the first step, not the whole goal.

You will notice that there's nothing in the whole extension patch and
framework that refers to a "module", those little executable binary
files whose name depend on the OS PostgreSQL is running on, and that you
manage at the file system level, in postgresql.conf with some GUCs, and
with the LOAD command.

You will also notice that we have been *very* careful not to taint any
extension related SQL command with the notion of files. That part is
well separated away and only meant to be known by extension authors and
packagers, not by mere mortals such as DBAs or users. The current patch
is willing to push that a little further away, making it optional even
to extension authors.

Those two facts didn't just happen. And I was not alone in designing the
system that way. Let's continue the design and its implementation! :)

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support