* Andrew Dunstan <andrew@dunslane.net> [080404 09:35]:
>
>
> Aidan Van Dyk wrote:
> >This changes the game slightly from trying to get systems to come with
> >PostreSQL "modules" installed into PostgreSQL by default, to where
> >systems come with PostgreSQL "module" *packages* (rpms, debs, pkg, etc)
> >installed by default, and the DB owners can do the "PostgreSQL install"
> >part themselves.
> >
> >Would this slight change of the game be of any value?
>
> No. "packages" has another meaning in the database context.
>
> I am going to point out AGAIN that we have already had a debate about
> this subject, not that long ago, including the name by which we should
> call these things. The consensus name then was "modules" and I think
> that was right.
>
> Those who do take cognizance of previous debates are doomed to repeat them.
Sorry - no, I'm not trying to debate the either the name or meaning of
modules in PostgreSQL - I understand that the concensus is "modules".
But I think you missed the whole point of my email.
Right now, PostgreSQL doesn't have a coherent "module" (or even package
for the specific database context) installation/infrastructure. It has
a flexible "use SQL to create domains/types/functions". This wasn't
about changing any of that.
This was simply about changing the user permissions needed to run CREATE
FUNCTION ... LANGUAGE "C" so that distros/packages could have whatever
module they want packaged (in system RPM/DEB/PKG context) and available
on the system in a way that databases owners could install them into
their PostgreSQL database (using the current psql < earthdistance.sql
methods) without getting ISP/superuser assistance.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
