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

Re: contrib function naming, and upgrade issues

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-22 20:16:59
Message-ID: 54F5CD25-6DA1-4C6A-8552-A904AEBEEBAA@hi-media.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

Le 22 mars 09 à 12:42, Andrew Gierth a écrit :
> Tom> I'm hesitant to do that when we don't yet have either a design
> Tom> or a migration plan for the module facility.  We might find we'd
> Tom> shot ourselves in the foot, or at least complicated the
> Tom> migration situation unduly.
>
> I've been thinking about this, and my conclusion is that schemas as
> they currently exist are the wrong tool for making modules/packages.

Agreed.
Still, schemas are useful and using them should be encouraged, I think.

> Partly that's based on the relative inflexibility of the search_path
> setting; it's hard to modify the search_path without completely
> replacing it, so knowledge of the "default" search path ends up being
> propagated to a lot of places.

pg_catalog is implicit in the search_path, what about having user  
schemas with the implicit capability too?

Then you have the problem of ordering more than one implicit schemas,  
the easy solution is solving that the same way we solve trigger  
orderding: alphabetically. Now, that could mean ugly user-facing  
schema names: we already know we need synonyms, don't we?

> There's a parallel here with operating-system package mechanisms; for
> the most part, the more usable / successful packaging systems don't
> rely on putting everything in separate directories, instead they have
> an out-of-band method for specifying what files belong to what  
> package.
>
> We already have a mechanism we could use for this: pg_depend. If an
> "installed package" was a type of object, the functions, types,
> operators, or any other kind of object installed by the package could
> have dependency links to it; that would (a) make it trivial to drop,
> and (b) pg_dump could check for package dependencies and, for objects
> depending on a package, emit only a package installation command  
> rather
> than the object definition.

Here's a sketch of what I came up with:
   http://wiki.postgresql.org/wiki/ExtensionPackaging

It's still needing some work before being a solid proposal, like for  
example handling cases where you want to pg_restore a database and  
insist on *not* caring about some extensions (pgq, londiste, slony  
things, cron restoring into pre-live systems). Or working out some  
versioning information and dependancies between modules.
What it misses the most is hackers acceptance of the proposed  
concepts, though.

> (I distinguish an "installed package" from whatever the package
> definition might be, since it's possible that a package might want to
> provide multiple APIs, for example for different versions, and these
> might be installed simultaneously in different schemas.)

Version tracking is yet to be designed in the document.
-- 
dim




In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2009-03-22 20:27:20
Subject: Re: contrib function naming, and upgrade issues
Previous:From: Tom LaneDate: 2009-03-22 19:17:01
Subject: Re: typedefs for indent

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