Re: RFC: PostgreSQL Add-On Network - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: RFC: PostgreSQL Add-On Network
Date
Msg-id m23a2hk0dy.fsf@hi-media.com
Whole thread Raw
In response to Re: RFC: PostgreSQL Add-On Network  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> e.g. pg_execute_commands_from_file('path/ to/file.sql'). It would not
[...]
> Then you need to add a catalog for holding the extensions metadata, like
[...]
> Now you can hack a CREATE EXTENSION command to fill-in the catalog, and
> the commands INSTALL EXTENSION and DROP EXTENSION to execute the given
> files. You have to invent a trick to be able to assign any SQL object
> created while executing the install file a dependency entry targeting
> the extension's catalog oid. As this is all done in a single given
> backend, my guess is that a static variable holding the oid would be
> enough, but you still have to touch all object creation code path.

Now that you have dependency information tracked, don't forget to add
pg_dump support by skipping any objects installed as part of an
extension and only issuing INSTALL EXTENSION foo; instead.

Then let pg_restore run this and complain loudly when the needed
extension entry does not exists yet, you have to CREATE and INSTALL the
extension on the new database before getting to restore your dump.

> You do *not* have to care about schema in any way *BUT* to prepend the
> search_path with pg_extension just before executing the install
> file. It's a new schema to provide in template databases, so that
> extensions default to creating their objects there. This new schema
> should be installed just before pg_catalog in the search_path in places
> that search for objects from their non qualified name. Full stop on this
> topic.
>
> Oh and special bonus if CREATE EXTENSION, given a newer version of an
> already installed extension, will register things so as to run the
> upgrade function from the newer version at INSTALL EXTENSION time. Or
> invent yet another syntax for upgrading.
>
> And. Wait. That's it.
>
> Oh, you could also try to turn plpgsql, plperl, plpython and their
> unstrusted variants into built-in extensions too, and contribs too. It
> would be nice if contribs where all CREATEd into template0 and template1
> and you only had to INSTALL EXTENSION hstore; for enjoying it. That'd be
> a Tom's easy evening I guess :)
>
> Anyone having the hours and skill required to do it? It's great fun,
> rewarding, everybody and his neighbour *want* it to be done, and I'll be
> as available as possible to answer mails, be there on IRC, and do the
> necessary political work if there's still some more to be done.
>
> Consider it as a gift I'm giving you: I'm refusing easily earned
> reputation by allowing you to code that for me ;)
>
> Regards,
> -- 
> dim
>
> PS: that ought to do it.

Hey, there's about a week left. :)
-- 
dim


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Add .gitignore files to CVS?
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL 8.5 Open Items