Re: contrib function naming, and upgrade issues

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