|From:||Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: contrib function naming, and upgrade issues|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)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.)
|Next Message||Andrew Gierth||2009-03-22 11:54:15||Re: contrib function naming, and upgrade issues|
|Previous Message||Andrew Gierth||2009-03-22 11:09:27||Re: contrib function naming, and upgrade issues|