| From: | "Zeugswetter Andreas OSB SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
|---|---|
| To: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: modules |
| Date: | 2008-04-03 11:33:42 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57902EB1A1F@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
> > The closest analogy to what I'm thinking is the perl CPAN
> or ruby gems.
I think this is more a developer thing. I don't think an ISP would want
all that automagic (and certainly does not do that for joe user).
> One thing that might be worth looking at is an install command at the
> SQL level, so the "INSTALL foo" would run the install script for the
foo
> module in the current database, assuming it's in the standard
location.
Yes.
> We don't have a central repository of non-standard modules, like CPAN,
> and so of course no facility for fetching / building / installing
them.
I think that is not a problem, since the service providers would rather
want
readily fetched built and regression tested modules, not anything fancy
or magic.
The readily built modules would simply be part of their binary
distibution.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2008-04-03 12:23:43 | Re: modules |
| Previous Message | windwxc | 2008-04-03 11:13:43 | question about complex type |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2008-04-03 12:23:43 | Re: modules |
| Previous Message | Tom Dunstan | 2008-04-03 09:11:29 | Re: modules |