Re: modules

* 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.