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 |
Date: | 2009-03-22 11:42:49 |
Message-ID: | 87skl5zsue.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "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.)
--
Andrew.
From | Date | Subject | |
---|---|---|---|
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 |