* Andrew Dunstan <[EMAIL PROTECTED]> [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, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature