Re: contrib function naming, and upgrade issues

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Robert Treat <xzilla@users.sourceforge.net> writes:>> We've been talking about this magical "proper module facility"
for>>a few releases now... are we still opposed to putting contrib>> modules in thier own schema?
 
Tom> I'm hesitant to do that when we don't yet have either a designTom> or a migration plan for the module facility.
Wemight find we'dTom> shot ourselves in the foot, or at least complicated theTom> 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.

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.

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.

(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.)

-- 
Andrew.