>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> Robert Treat <xzi...@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 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. 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
