Re: [HACKERS] modules missing from Application Stack Wizard?
On Wed, Jul 8, 2009 at 11:11 PM, Kasia Tuszynskaktuszyn...@esri.com wrote: Hello Postgres Hackers, We have begun testing Postgres 8.4 on windows, beginning with the installer. We have noticed that several additional modules which are usually installed through the Application Stack Wizard are missing from the list of available modules like PostGIS or the developer options. Are those available through some other option or an additional installation? I'm not sure what you mean by 'developer options'. The only ones we haven't published yet that are 8.4-specific are PostGIS and Slony. For Windows, the PostGIS package comes from the PostGIS project, so we're waiting on them (I think they're just about to go GA). For Slony, and PostGIS on Linux/Mac, the packages are currently in QA. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Hi, D'Arcy J.M. Cain wrote: ... Yes but what I am suggesting goes beyond that. My idea is that there is a modules directory that contains a file for each installable module. This file would contain all the information about the module such as name, version, where to get the actual package, an MD5 checksum of the package, minimum and maximum PostgreSQL versions required, etc. I'd suggest the approach taken by debian apt rather then pkgsrc - instead of maintaining a whole directory structure on client side have a couple of files as database - I guess even using the database itself would work - and RDP (basically xml over http) which would be different from apt approach but we are dealing with much less modules. The most important thing we could learn from apt is to use cryptography to secure installed modules - instead of just maintaining package integrity with md5. After all, a database module can do almost everything - so I'd rather know if I trust the packager. Just my 0.2c Tino -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Sat, 05 Apr 2008 02:17:10 +0100 Gregory Stark [EMAIL PROTECTED] wrote: I was inclined to dismiss it myself but I think the point that's come up here is interesting. The ISP has to not just install an RPM or type make install in some source tree -- but actually log into each customer's database and run an SQL script. That does seem like more work and more risk than a lot of ISPs will be willing to take on. Why wouldn't you just run it against template1 so that it is available in every database created after that? -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Sat, 05 Apr 2008 02:17:10 +0100 Gregory Stark [EMAIL PROTECTED] wrote: I was inclined to dismiss it myself but I think the point that's come up here is interesting. The ISP has to not just install an RPM or type make install in some source tree -- but actually log into each customer's database and run an SQL script. That does seem like more work and more risk than a lot of ISPs will be willing to take on. On (k)Ubuntu you can apt-get install postgresql-contrib-8.3 which puts everything in the right places, all you have to do then is to run the sql scripts in /usr/share/postgresql/8.3/contrib/ as user postgres... But of course you need the ISP to do it for you if you are not superuser. Some will bother to run a few commands for a user, some won't... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
D'Arcy J.M. Cain [EMAIL PROTECTED] writes: Why wouldn't you just run it against template1 so that it is available in every database created after that? Well maybe you don't want *every* customer to have it or not every customer wants it. And also, what do you do about modules you add after customers have signed up? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Fri, Apr 04, 2008 at 08:22:51PM -0400, Aidan Van Dyk wrote: Today was the first time I actually ever looked at the create function and create language code, and I'm actually suprised at how little contract there seems to be between a object file and the created function. But since it's always been guarded by super-user, it's obviously not been an issue... There was once a discussion about allowing people to add declarations to the C code indicating the types and returns type to avoid stupid errors (you could just say CREATE FUNCTION foo FROM module.so and it would get the types/volitility/etc from the module). It even went so far that you could build the install/deinstall scripts into the module itself, so all postgres had to do was dlopen() the module it could access the install script. It fails due to the fact that modules that don't require compilation are left out in the cold... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] modules
On Sat, Apr 5, 2008 at 5:11 PM, Martijn van Oosterhout [EMAIL PROTECTED] wrote: It even went so far that you could build the install/deinstall scripts into the module itself, so all postgres had to do was dlopen() the module it could access the install script. It fails due to the fact that modules that don't require compilation are left out in the cold... Well, there's no reason you can't allow both... look for module_install() in the lib if it's there, or install.sql if it's not. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Sat, 05 Apr 2008 09:18:07 +0200 PFC [EMAIL PROTECTED] wrote: But of course you need the ISP to do it for you if you are not superuser. Some will bother to run a few commands for a user, some won't... Right. I encourage my competitors to do nothing for their clients. I will continue to help mine any way I can. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Fri, Apr 4, 2008 at 10:48 AM, Jeremy Drake [EMAIL PROTECTED] wrote: My opinion is, it doesn't matter what you call the modules/contrib stuff if I can't use it, and I can't use it if it is not loaded in my database, and I can't load it without superuser privileges. Right. Which is why some of us have been suggesting a model where all modules currently in contrib are installed by default, but not enabled until a database owner actually issues some sort of Install module foo or whatever it looks like. Database owner privs are probably as low as we can reasonably set the bar... is that sufficiently low to be useful? If not, I suppose that we could add a specific install / uninstall module privilege that could be granted to non-db-owner users if that's the way the ISP prefers to work. Regarding PostGIS etc, my hope is that if we standardize the installation of postgresql modules in this manner, it will be much easier for sysadmins to e.g. yum install postgis - they don't have to run any SQL scripts by hand, they can get packages built for their platform and distributed using the preferred platform distribution method, and the modules will only be enabled for those users that specifically enable them in their databases. We can't force sysadmins to install random third party extensions to postgresql, but we can make it a lot easer than it currently is. Alternately, if that's still not enough, then if we do standardise the interface it would be easier to bundle third party modules that live outside the main source tree - just stick em in /modules when building the tar files and they'll end up installed and ready-to-enable when built. Hmm. We could even do that for existing contrib modules if we want them to live outside the core project - for example because their maintainers don't need commit access to core. It would be easy enough to have the buildfarm fetch blessed modules from their real location (pgfoundry?) so that we maintain good test coverage. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Fri, Apr 04, 2008 at 02:23:31PM +0530, Tom Dunstan wrote: Right. Which is why some of us have been suggesting a model where all modules currently in contrib are installed by default, but not enabled until a database owner actually issues some sort of Install module foo or whatever it looks like. Reading the message that starts this thread I note the problem is underspecified. We have three properties of the provider: a. You have superuser priveledges on your database b. You have a shell where you can compile programs c. Your provider has instlled the postgresql-contrib package With either ab or ac you're home. However, without a you're stuffed. What I want to know is: does the situation where you have only c but not b or a happen often? Because that we *can* do something about. Or are we dealing primarily with providers where you have none of the above? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] modules
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. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
* Jeremy Drake [EMAIL PROTECTED] [080404 01:27]: My opinion is, it doesn't matter what you call the modules/contrib stuff if I can't use it, and I can't use it if it is not loaded in my database, and I can't load it without superuser privileges. Would it be possible to change the rules a bit to make this more friendly? Right now, the superuser needed part of installing a module (like earthdistance or cube) is the LANGUAGE C functions, and that's the part that allows the user to load random code that can gets run as the postgres user. All the other function/domain stuff doesn't need superuser privileges. What if you didn't need super-user privileges to load C functions, on the conditions that: 1) There is no / in the obj_file filename (or some other sanitizing rules) 2) You're database owner This follows the precedence of the CREATE LANGUAGE, which allows database owners to install a language as long as it's known on the system. Doing this still wouldn't help the poor user who's ISP refuses to do anything besides ./configure make make install of base PostgreSQL, but it does allow distros/packages to make more packages available that don't need to be on in every database, but where database owners can easily enable any of the installed packages without further ISP admin intervention. 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? 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
Re: [HACKERS] modules
* Andrew Dunstan [EMAIL PROTECTED] [080404 10:17]: Aidan Van Dyk wrote: 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. That's not going to happen, at least not like that - the security implications are just horrible. We have recently relaxed the rules relating to installation of trusted languages by database owners. But to extend that to modules in general we'd need some way of designating modules as safe or not. Excatly - this was just a one simple method of marking modules as safe; if the object files are found in the safe place (possibly the location of pg_config --pkglibdir, possibly elsewhere, specified by a GUC, possibly something else), then they could be considered safe for the database owner to use as a LANGUAGE C definition. The safe location could be somewhere else. Like I said earlier, this changes the game (that Jermery original said was the problem - namely that a module is useless if it's not installed, and he can't install it unless he's superuser) only slightly. It's just a method for packagers/distros/sysadmins to mark modules as safe. If the packages (rpm/deb/pkg context) are installed on the system, and the files are in the location considered to mark them safe), then any DB owner could install them into their DB. It's just one possible way to mark modules as safe. Just as another method for used for languages was to use a system table like pg_pltemplate. But it's something that I think *may* be better than pg_pltemplate, because pg_pltemplate re-enforces the notion that only things in core (and installed in core by default) can be considered safe, because really, how is some dpkg installation of plruby or plperl or pljava automatically going to get it's info into pl_pltemplate without specific knowledge of the port your cluster (or all your clusters) are on, superuser connection details, etc. But maybe some system table *is* the way to make object files as safe, so a super-user *is* required to add some row to some table to mark it as safe. I'm looking for *some* way to make a way for 3rd party modules to be considered safe so somebody (non-superuser) can install them into a PG database. 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
Re: [HACKERS] modules
* 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
Re: [HACKERS] modules
On Thu, 3 Apr 2008, Joshua D. Drake wrote: IMO the core modules should be compiled via configure with something like: ./configure --enable-module=ALL If you really want to make the problems with using contrib modules go away, so they are a) installed even by lazy ISPs who just do compile/make/make install, and b) not viewed as second-class citizens when people have to ask them to be installed, this won't do it. You should default to installing all the modules and provide configure options to turn them off instead. All PostgreSQL installations should have them all available (but not installed in the database, as you point out) unless someone goes out of their way to circumvent that. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Aidan Van Dyk wrote: 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. That's not going to happen, at least not like that - the security implications are just horrible. We have recently relaxed the rules relating to installation of trusted languages by database owners. But to extend that to modules in general we'd need some way of designating modules as safe or not. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Aidan Van Dyk [EMAIL PROTECTED] writes: What if you didn't need super-user privileges to load C functions, on the conditions that: 1) There is no / in the obj_file filename (or some other sanitizing rules) 2) You're database owner That's an interesting idea. It has the property that no super-user is required to do any fiddling *inside* your database. That is, the ISP can just do CREATE DATABASE and then leave you have at it without having to deal with installing modules or granting any permissions inside your database. It also opens the door to .deb packagers being able to put pgfoundry modules in the same space. No other suggestion has offered any help to anything except blessed contrib modules. I would suggest a guc for the safe place and I would suggest it be a list of places. And I would suggest that for OS packagers they really want two locations on that list, something like: /usr/lib/postgresql/modules;/usr/local/lib/postgresql/modules That way users can compile and install their own modules into /usr/local without interfering with modules which come from OS packages. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Assuming others think something like this might be interesting, would something to do this be an OK candidate for my first patch, if only to start this ball rolling? a. * Gregory Stark [EMAIL PROTECTED] [080404 14:57]: Aidan Van Dyk [EMAIL PROTECTED] writes: What if you didn't need super-user privileges to load C functions, on the conditions that: 1) There is no / in the obj_file filename (or some other sanitizing rules) 2) You're database owner That's an interesting idea. It has the property that no super-user is required to do any fiddling *inside* your database. That is, the ISP can just do CREATE DATABASE and then leave you have at it without having to deal with installing modules or granting any permissions inside your database. It also opens the door to .deb packagers being able to put pgfoundry modules in the same space. No other suggestion has offered any help to anything except blessed contrib modules. I would suggest a guc for the safe place and I would suggest it be a list of places. And I would suggest that for OS packagers they really want two locations on that list, something like: /usr/lib/postgresql/modules;/usr/local/lib/postgresql/modules That way users can compile and install their own modules into /usr/local without interfering with modules which come from OS packages. -- 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
Re: [HACKERS] modules
Gregory Stark [EMAIL PROTECTED] writes: Aidan Van Dyk [EMAIL PROTECTED] writes: What if you didn't need super-user privileges to load C functions, on the conditions that: 1) There is no / in the obj_file filename (or some other sanitizing rules) 2) You're database owner That's an interesting idea. And utterly, utterly insecure. The fact that the referenced object file is a trusted Postgres module isn't enough to make it safe --- the user can still play hob with the system by creating functions with the wrong argument/result types, pointing at exported symbols that weren't meant to be callable functions, creating broken index opclasses from the functions, etc. I think you'd need to move the security gating up a level, and somehow see the SQL-language installation and deinstallation scripts as trusted. This goes back to the question of what is a module anyway. Like Andrew, I'm a bit disturbed that people feel free to propose to implement this stuff when they evidently have read none of the prior discussions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Sat, Apr 5, 2008 at 12:22 AM, Gregory Stark [EMAIL PROTECTED] wrote: Aidan Van Dyk [EMAIL PROTECTED] writes: What if you didn't need super-user privileges to load C functions, on the conditions that: 1) There is no / in the obj_file filename (or some other sanitizing rules) 2) You're database owner That's an interesting idea. It has the property that no super-user is required to do any fiddling *inside* your database. That is, the ISP can just do CREATE DATABASE and then leave you have at it without having to deal with installing modules or granting any permissions inside your database. Maybe it didn't come across, but it's exactly what I've been suggesting in this thread, albeit a slightly different solution. My idea was to have an installed module, and rather than allowing $database_owner to create C language functions based on what are really implementation details for the given extension, just allow them to say e.g. install module postgis; or equivalent - this would then run either some init function or an appropriately named and placed install script that would take care of everything. A module would be expected to provide an uninstall script, too, to allow uninstall module foo or whatever. Under this scenario end users don't need access to the install scripts, don't need to know the exact library name, and aren't given the ability to e.g. create C language functions in ways that weren't intended, like declaring one taking the wrong variable types or something. The sysadmin can trust the module to do the right thing - they don't have to trust the user. As far as getting sysadmins to install contrib, this then becomes really easy - just install them all by default and let database owners install them into their own dbs as they wish. It also opens the door to .deb packagers being able to put pgfoundry modules in the same space. No other suggestion has offered any help to anything except blessed contrib modules. Well, I actually was approaching the problem from the point of view of creating yum installable rpms - killing contrib was just a nice side effect :) I would suggest a guc for the safe place and I would suggest it be a list of places. And I would suggest that for OS packagers they really want two locations on that list, something like: /usr/lib/postgresql/modules;/usr/local/lib/postgresql/modules That way users can compile and install their own modules into /usr/local without interfering with modules which come from OS packages. +1. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Greg Smith [EMAIL PROTECTED] writes: On Thu, 3 Apr 2008, Joshua D. Drake wrote: IMO the core modules should be compiled via configure with something like: ./configure --enable-module=ALL If you really want to make the problems with using contrib modules go away, so they are a) installed even by lazy ISPs who just do compile/make/make install, and b) not viewed as second-class citizens when people have to ask them to be installed, this won't do it. Indeed. If anything, this will make the problem worse by increasing the perception gap between contrib modules and modules that don't come with the core distribution. IMHO, the ideal situation would be that the only stuff in contrib is stuff that needs to be maintained together with the core code --- an example is pg_controldata, because it looks at data structures that we change on a frequent basis. We need to be looking for ways to increase the status of stuff that doesn't come with the core distro, not create an even stronger gap between the ins and the outs. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Gregory Stark [EMAIL PROTECTED] writes: I would suggest a guc for the safe place and I would suggest it be a list of places. And I would suggest that for OS packagers they really want two locations on that list, something like: /usr/lib/postgresql/modules;/usr/local/lib/postgresql/modules That way users can compile and install their own modules into /usr/local without interfering with modules which come from OS packages. That seems like a great way to persuade people that safe isn't so safe after all. If I were the kind of ISP that doesn't want people to have database superuser, there's no way on earth that I'd accept a setting like that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: I would suggest a guc for the safe place and I would suggest it be a list of places. And I would suggest that for OS packagers they really want two locations on that list, something like: /usr/lib/postgresql/modules;/usr/local/lib/postgresql/modules That way users can compile and install their own modules into /usr/local without interfering with modules which come from OS packages. That seems like a great way to persuade people that safe isn't so safe after all. If I were the kind of ISP that doesn't want people to have database superuser, there's no way on earth that I'd accept a setting like that. Huh? Nobody's forcing the sysadmin to *install* any modules. But if they do they shouldn't have to overwrite files that came with their OS. All I'm saying is that distribution packagers need two directories, one for files installed as part of a distribution package and one for files the sysadmin wants to install himself for his users. That's exactly like, say, /usr/share/emacs/site-lisp and /usr/local/share/emacs/site-lisp. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Tom Lane wrote: IMHO, the ideal situation would be that the only stuff in contrib is stuff that needs to be maintained together with the core code --- an example is pg_controldata, because it looks at data structures that we change on a frequent basis. We need to be looking for ways to increase the status of stuff that doesn't come with the core distro, not create an even stronger gap between the ins and the outs. Well, I think we need some more than that, although possibly we don't need everything that's in contrib now. I think it's important that we keep a few in the core distribution as exemplars of the various module types (broadly: PLs, types, function libraries). The example I have in mind is Perl, as I have referred to before. It comes with a number of useful modules (e.g. File::Find, and CGI) that don't have to be in the perl core distribution but are very widely used and so having them there makes some sense. I do agree that we need to embark on some education to help make non-core modules more acceptable to the world at large. A standard build and install framework and a somewhat trustable repository would help a lot with that. If people want to start building out stuff now on the if we build it they will come theory, then that's where I'd personally encourage them to put effort. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Andrew Dunstan [EMAIL PROTECTED] writes: The example I have in mind is Perl, as I have referred to before. It comes with a number of useful modules (e.g. File::Find, and CGI) that don't have to be in the perl core distribution but are very widely used and so having them there makes some sense. What's different about those is that they are developed primarily as CPAN modules. The ones in the perl source are just copies of the CPAN module installed by default. Would that help earn respect for pgfoundry? Modules there would have something to aspire to if they grew to be considered indispensable rather than just be doomed to being forgotten and ignored. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
* Tom Lane [EMAIL PROTECTED] [080404 16:12]: And utterly, utterly insecure. The fact that the referenced object file is a trusted Postgres module isn't enough to make it safe --- the user can still play hob with the system by creating functions with the wrong argument/result types, pointing at exported symbols that weren't meant to be callable functions, creating broken index opclasses from the functions, etc. So those are all good reasons why we can't just assume a obj_file safe to be used for a C language function with the current framework. Would a stronger contract mechanism between PG and symbols loaded from object files used for functions... Today was the first time I actually ever looked at the create function and create language code, and I'm actually suprised at how little contract there seems to be between a object file and the created function. But since it's always been guarded by super-user, it's obviously not been an issue... I think you'd need to move the security gating up a level, and somehow see the SQL-language installation and deinstallation scripts as trusted. This goes back to the question of what is a module anyway. And, unfortunately, I haven't seen any of those who have a thorough enough knowledge and understanding of the whole system and security issues talking a whole lot about that, well, beside shooting gaping holes through lame ideas like mine ;-) Maybe it's just because the problem really *is* that hard. But I've seen some pretty amazing features come in to PG over the past years, so I know hard problems are solved by you guys... Unfortunately, the current state really does seem to mean that the feature of modularity really is the kiss of death, since things are actively pushed out from core to be modular projects, making them unusable for most people... Like Andrew, I'm a bit disturbed that people feel free to propose to implement this stuff when they evidently have read none of the prior discussions. Well, I'm happy to go back to lurking for now... Maybe after a few years I'll have heard and seen more discussions and know better next time ;-) -- 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
Re: [HACKERS] modules
On Fri, 4 Apr 2008 20:22:51 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: Unfortunately, the current state really does seem to mean that the feature of modularity really is the kiss of death, since things are actively pushed out from core to be modular projects, making them unusable for most people... Is there anything but anecdotal evidence for this statement? I mean, yes, some ISPs will make life hard for their users and some SHAMELESS PLUG http://www.Vex.Net/; / will work with their clients to deliver what they need. Besides, most users of PostgreSQL are probably enterprise users or users running off of their own systems who have all the access they need. How big is this problem really? -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
D'Arcy J.M. Cain [EMAIL PROTECTED] writes: On Fri, 4 Apr 2008 20:22:51 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: Unfortunately, the current state really does seem to mean that the feature of modularity really is the kiss of death, since things are actively pushed out from core to be modular projects, making them unusable for most people... Is there anything but anecdotal evidence for this statement? I mean, yes, some ISPs will make life hard for their users and some SHAMELESS PLUG http://www.Vex.Net/; / will work with their clients to deliver what they need. Besides, most users of PostgreSQL are probably enterprise users or users running off of their own systems who have all the access they need. How big is this problem really? I was inclined to dismiss it myself but I think the point that's come up here is interesting. The ISP has to not just install an RPM or type make install in some source tree -- but actually log into each customer's database and run an SQL script. That does seem like more work and more risk than a lot of ISPs will be willing to take on. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Aidan Van Dyk wrote: Unfortunately, the current state really does seem to mean that the feature of modularity really is the kiss of death, since things are actively pushed out from core to be modular projects, making them unusable for most people... Really? What have we pushed out that has died? The only thing I can recall of any significance being pushed out is the client libraries, and most or all of those are still alive and kicking. Like Andrew, I'm a bit disturbed that people feel free to propose to implement this stuff when they evidently have read none of the prior discussions. Well, I'm happy to go back to lurking for now... Maybe after a few years I'll have heard and seen more discussions and know better next time ;-) Don't take it personally. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
* Andrew Dunstan [EMAIL PROTECTED] [080404 21:54]: Well, I'm happy to go back to lurking for now... Maybe after a few years I'll have heard and seen more discussions and know better next time ;-) Don't take it personally. I don't, and for the record, I'm actually quite glad that the bar for entry is so high. That's one of the things that keeps the quality of PG so high. But that also means that some times, those more in the know have to put up with incomplete thoughts from those of us who haven't been immersed -hackers for years yet... ;-) Apologies to people if my ill-thought and incomplete idea either put anybody out, or got anybody's hopes up for not... 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
Re: [HACKERS] modules
I had some thoughts about similar issues when looking at what it would take to make pl/java yum-installable. The end goal was to be able to say e.g. yum install pljava; echo create language pljava; | psql mydb. Currently there's a non-trivial install process involving running an sql script and java class. My idea was to have a createlang_init kind of function that could be called when installing a language to set up appropriate functions, tables etc. There would be a similar function to clean up when dropping the lang. On Thu, Apr 3, 2008 at 6:12 AM, Ron Mayer [EMAIL PROTECTED] wrote: Agreed. Such a mechanism would only really apply for things that are installed in the database. But from an end user's point of view, installing functions, index types, languages, data types, etc all see to fit the pg_install postgis -d mydb, pg_install pl_ruby -d mydb, etc. pattern pretty well. Well, there are a couple of major differences. Firstly cpan, gem etc are able to install all required dependencies themselves, at least where no native compilation is required, because they are basically their own platform. PG libs more or less require a build environment. Secondly, and more importantly, module installation for those environments happens once and is global; installation of native libs for pgsql is different to instllation in a database. What happens in the above scenario when the postgis libs are already installed? And what about cleanup? Also, it would seem that such an install process requires the server to be running - so much for packaging as RPMs/debs/win32 installer etc. I think a better solution would be to have a pg_install be a distribution mechanism capable of installing binaries / scripts / other resources, but have pgsql itself handle module installation into a particular database. I'm thinking a CREATE MODULE foo; kind of thing that would be capable of finding either a module install script or a foo_init() function in libfoo.so/foo.dll. Similarly for cleanup, so cleanup isn't dependent on pg_install lying around or the version that was install still being the latest when pg_install looks for an uninstall script. This would allow modules to be installed site-wide but optionally created / dropped from specific databases in a much saner manner, and standard pgsql permissions could apply to installation of modules. It would also allow creation of rpms etc that can be shipped by a distribution, and then enabled by the user by calling the appropriate command. Finally, setting up modules so they can be built for Windows, especially using MSVC, will probably be quite a challenge. Indeed. Seems ruby gems give you the option of installing a ruby version or a windows version that I'm guessing has pre-compiled object files. Yeah, setting up Cygwin to build postgres is a pain (or was when I last did so). If we're serious about setting up a central repository, we should consider having a virtualized windows machine capable of building binaries for the modules that people upload. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Zeugswetter Andreas OSB SD wrote: 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). I think you are missing an essential part of the vision. This is not just targetted at developers. Binary distro authors typically include a huge number of CPAN modules as well as core Perl, and ISPs typically install them. We want to have something CPAN-like so we can get the same effect. At any rate, that's a bit blue sky right now. I haven't seen any disagreement with our kissing contrib goodbye as a name, so let's work on that. Unfortunately, that's going to involve a bit of pain, including in the buildfarm, whose client relies on the name. I'll go to work on fixing that, and we can get a new version out so when we make the switch the buildfarm doesn't go dark. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 At any rate, that's a bit blue sky right now. I haven't seen any disagreement with our kissing contrib goodbye as a name, so let's work on that. Unfortunately, that's going to involve a bit of pain, Yes, I'm not sure I see the point of it. It's got a bad name, but changing it is just putting lipstick on a pig. End users don't know, and don't care, about contrib. Sysadmins and casual DBAs only care what they can yum install. That only leaves packagers and hard-core developers, both of whom already know how contrib works. Not that I wouldn't want to see some of the good ideas raised in this thread explored. In particular, I'd love to see some of the more standard contrib things installable as simple as: postgres=# INSTALL earthdistance; Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200804030953 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkf04VUACgkQvJuQZxSWSsjmPACeMoaDTXgjqXBKlthPad6D3sWV qooAn2y0cwnafYwnGonGBEq/6IAbXzlF =SO7r -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
* Greg Sabino Mullane [EMAIL PROTECTED] [080403 09:54]: Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. But that begs the question of *why* it's a kiss of death? For instance, in perl land, having something in CPAN and not in perl core is most certainly *not* a kiss of death? Why is it so different for PostgreSQL? Is it because the infrastructure behind CPAN is much better than that behind pgfoundry? Or is it because CPAN is better vetted and organized than pgfoundry? Or is it because the projects that go into CPAN are better quality and projects in pgroundry? Or is it something else? I'm pretty sure the answers to the above questions aren't all yes... 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
Re: [HACKERS] modules
Greg Sabino Mullane wrote: At any rate, that's a bit blue sky right now. I haven't seen any disagreement with our kissing contrib goodbye as a name, so let's work on that. Unfortunately, that's going to involve a bit of pain, Yes, I'm not sure I see the point of it. It's got a bad name, but changing it is just putting lipstick on a pig. End users don't know, and don't care, about contrib. Sysadmins and casual DBAs only care what they can yum install. That only leaves packagers and hard-core developers, both of whom already know how contrib works. If this were at all true we would not not have seen the complaints from people along the lines of My ISP won't install contrib. But we have, and quite a number of times. We have concrete evidence that calling it contrib actually works against us. It's also worth pointing out that WE HAVE HAD THIS DISCUSSION BEFORE. Sometimes I get rather frustrated by our habit of turning time into a circle and running Groundhog Day. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, Apr 3, 2008 at 8:25 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
If this were at all true we would not not have seen the complaints from
people along the lines of My ISP won't install contrib. But we have, and
quite a number of times. We have concrete evidence that calling it contrib
actually works against us.
It's hard to see ISPs who won't install contrib from installing
${random module} from the big bad internet as has been discussed in
this thread, but who knows?
If we go with a solution that allows users to say install mymodule;
or whatever into their own database, is there any reason not to
install (as in make install) all modules currently called contrib by
default? Are there any security issues with modules in there? I seem
to remember something coming up involving dblink a while back...
Cheers
Tom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Apr 2008 21:03:05 +0530
Tom Dunstan [EMAIL PROTECTED] wrote:
On Thu, Apr 3, 2008 at 8:25 PM, Andrew Dunstan [EMAIL PROTECTED]
wrote:
If this were at all true we would not not have seen the complaints
from people along the lines of My ISP won't install contrib. But
we have, and quite a number of times. We have concrete evidence
that calling it contrib actually works against us.
It's hard to see ISPs who won't install contrib from installing
${random module} from the big bad internet as has been discussed in
this thread, but who knows?
Sure it is. The very word contrib brings about ideas of things like:
Unstable, Cooker, unofficial.
modules is completely different (from a perception perspective).
IMO the core modules should be compiled via configure with something
like:
./configure --enable-module=ALL
or
./configure --enable-module=pgcrypto --enable-module=cube
This would install all the modules but not enable them in the database
itself (of course). This could also be extended to the pls so that we
have exactly one mechanism to control those options as well.
./configure --enable-module=pgcrypto --enable-module=plperl
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH9PwCATb/zqfZUUQRAoWtAKCdbdcv4KdOIdiF8gcjebWTIrub1gCgg8RU
QaatCVhlETRkA6+5wyYNdRM=
=z1gI
-END PGP SIGNATURE-
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Am Donnerstag, 3. April 2008 schrieb Andrew Dunstan: If this were at all true we would not not have seen the complaints from people along the lines of My ISP won't install contrib. But we have, and quite a number of times. We have concrete evidence that calling it contrib actually works against us. ISPs also won't install additional Perl modules, for example. Yet, CPAN does exist successfully. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, Apr 3, 2008 at 9:17 PM, Joshua D. Drake [EMAIL PROTECTED] wrote:
It's hard to see ISPs who won't install contrib from installing
${random module} from the big bad internet as has been discussed in
this thread, but who knows?
Sure it is. The very word contrib brings about ideas of things like:
Unstable, Cooker, unofficial.
Point taken, and I completely agree. Part of the problem is that we
have explicitly encouraged this perception, ie it's in contrib so the
barrier to entry is lower. That may not be the case anymore, or it
may just be that the bar is really really high for non-contrib stuff
vs other projects. Whatever the actual case is, I agree that the name
is unfortunate.
When I wrote the above I was thinking about it from the other way
around: doing a cpan or gem install of some random module seems even
less safe to me, but maybe I'm just revealing confidence in pgsql or
fear of some cpan code etc that ISPs don't share.
This would install all the modules but not enable them in the database
itself (of course). This could also be extended to the pls so that we
have exactly one mechanism to control those options as well.
./configure --enable-module=pgcrypto --enable-module=plperl
That's basically where I was heading, although I took it a step
further: why not build and install all possible modules by default, if
we think they're up to quality?
One answer is: what do you do if some required library isn't
available? Do you fail with an error message or just don't build that
module? I don't like the idea of e.g. accidentally and silently not
installing pl/perl just because the sysadmin hadn't installed their
perl-devel package or whatever.
--enable-module=ALL could be pretty good, though, especially if it
build pl/perl etc that most sysadmins will want to install but do so
in less configure args. :)
Cheers
Tom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Apr 2008 21:45:52 +0530 Tom Dunstan [EMAIL PROTECTED] wrote: This would install all the modules but not enable them in the database itself (of course). This could also be extended to the pls so that we have exactly one mechanism to control those options as well. ./configure --enable-module=pgcrypto --enable-module=plperl That's basically where I was heading, although I took it a step further: why not build and install all possible modules by default, if we think they're up to quality? Good point. One answer is: what do you do if some required library isn't available? If we build by default, then when a library isn't found the configure output tells you: Looking for Perl Development packages: No , disabling plperl build. --enable-module=ALL could be pretty good, though, especially if it build pl/perl etc that most sysadmins will want to install but do so in less configure args. :) Right. I am using the Apache model here. Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9QQ2ATb/zqfZUUQRAsD9AJ9b9/12ZtaJ/CpnQ3y0xH7U3a0EYACfVeUJ FKUyEmuuw9nx3F+sk4mL2eQ= =sA7I -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Aidan Van Dyk wrote: * Greg Sabino Mullane [EMAIL PROTECTED] [080403 09:54]: I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. But that begs the question of *why* it's a kiss of death? For instance, in perl land, having something in CPAN and not in perl core is most certainly *not* a kiss of death? Why is it so different for PostgreSQL? Is it because the infrastructure behind CPAN is much better than that behind pgfoundry? I wouldn't say one is better than the other. PGFoundry and CPAN have totally disjoint feature sets. PgFoundry's like SoruceForge + Bugtrackers + Discussion Forums + Surveys + Mailing Lists -- pretty much everything except installable packages. CPAN and RubyGems is very much focused on installable packages. Or is it because CPAN is better vetted and organized than pgfoundry? Or is it because the projects that go into CPAN are better quality and projects in pgroundry? To simplify those two: CPAN contains installers that mostly just work. PGFoundry contains mostly works-in-progress without installers. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
D'Arcy J.M. Cain wrote: Check out NetBSD pkgsrc as a model. It is very flexible. One nice thing would be the ability to specify where the packages are rather than always insisting that they be on pgfoundry. Yup - a feature shared by RubyGems: gem install rails –source http://gems.rubyonrails.org Many of the most popular modules seem to live outside of pgfoundry anyway (postgis, the contrib ones, etc); so I'd think even if we maintain a central repository we want to make sure it can install from other sites. Perl and Ruby are languages - Postgres is a very different animal. ...Overall though I don't think that what is being installed to changes much. The basics remain the same - define the package with latest version, download if necessary,check that the source package is the correct, tested one, build, install, register. +1. From the end user I think he cares that the software is installed with the required dependencies and passes any included regression tests. Bonus points if it also registers itself in his database. And in the ruby/gems world the Windows guys seem not to have liked the check...source packages...build so they include precompiled windows libraries for those guys in many Ruby Gems. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, 3 Apr 2008 13:54:11 - Greg Sabino Mullane [EMAIL PROTECTED] wrote: Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. Yes! I have plenty of FTP servers to put up my own open source projects. It would annoy me if I was forced to use someone else's development environment. Whatever we do should allow for packages to be picked up from anywhere. We can use MD5 checksums to assure users that no one has changed the file since it was tested and packaged. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2008, Joshua D. Drake wrote: Tom Dunstan wrote: One answer is: what do you do if some required library isn't available? If we build by default, then when a library isn't found the configure output tells you: Looking for Perl Development packages: No , disabling plperl build. That might easily go unnoticed in amongst all the other configure output. It would only be effective if the messages were repeated again at the end of the configure, or configure somehow draws attention to the fact that there was a problem. Another approach I've come across is to fail with an error message like Perl development files not found, required to build module plperl. Install these files or configure with --disable-module=plperl Cheers, BJ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFH9Qfu5YBsbHkuyV0RAmKIAJ9eBkAGaw5kBmahk4CzJ4JbrkmitACff9DB eYYSl1SiANAaAyky/3QBSIs= =Fg12 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Apr 2008 12:35:31 -0400 D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008 13:54:11 - Greg Sabino Mullane [EMAIL PROTECTED] wrote: Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. Pgfoundry is not a kiss of death except that you spread falsehoods like that. PGfoundry is a very alive project that is constantly adding content and has continuing and very active projects. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9QjVATb/zqfZUUQRAmuMAKCR/+mgHqB9TTsdI0G3Ax2Y5ry4SQCfQMNt d7+jcUa3pDirWo34n7dqg2o= =p4Oq -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Andrew Dunstan wrote: Ron Mayer wrote: Andrew Dunstan wrote: Tom Lane wrote: as having better system support for packages or modules or whatever you want to call them; and maybe we also need some marketing-type ...re-raise the question of getting rid of contrib... The PostgreSQL Standard Modules. While renaming, could we go one step further and come up with a clear definition of what it takes for something to qualify as a module? In particular I think standardizing the installation would go a long way to letting packagers automate the installation of modules from pgfoundry. I think it'd be especially cool if one could one-day have a command pg_install_module [modulename] -d [databasename] and it would magically get (or verify that it had) the latest version from pgfoundry; compile it (if needed) and install it in the specified database. The closest analogy to what I'm thinking is the perl CPAN or ruby gems. Yes, and the CPAN analogy that has been in several minds, but it only goes so far. Perl and Ruby are languages - Postgres is a very different animal. We do in fact have some support for building / installing some modules in a standard way. It's called pgxs and it is used by quite a number of existing modules. On Windows we also have the StackBuilder application which is used for installation of binary modules. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, 3 Apr 2008 09:41:57 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Apr 2008 12:35:31 -0400 D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008 13:54:11 - Greg Sabino Mullane [EMAIL PROTECTED] wrote: Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. Pgfoundry is not a kiss of death except that you spread falsehoods like that. PGfoundry is a very alive project that is constantly adding content and has continuing and very active projects. Eep! Careful with attributions. There is not a single word of mine in what you included. I know it technically says that but since your comments were directed at Greg you really should have replied to his email and not to mine that included his. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Apr 3, 2008, at 7:01 AM, Aidan Van Dyk wrote: * Greg Sabino Mullane [EMAIL PROTECTED] [080403 09:54]: Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. But that begs the question of *why* it's a kiss of death? For instance, in perl land, having something in CPAN and not in perl core is most certainly *not* a kiss of death? Why is it so different for PostgreSQL? Is it because the infrastructure behind CPAN is much better than that behind pgfoundry? Yes. I can install a package from a CPAN mirror with a one-line incantation and be sufficiently sure it works that on the very rare occasions it doesn't I'm really surprised. On the Windows end of things I can usually get pre-built binaries of those same packages installed, in the cases where a compiler is needed to build them. The exact process is a bit different, but it's consistent across most packages and uses the same namespace. Or is it because CPAN is better vetted and organized than pgfoundry? Partly. Vetted is partly self-vetting - you're expected to pass your self tests and install cleanly before you publish to CPAN. The naming hierarchy helps with the CPAN organization, and makes it easier to use than the trove approach, once you're familiar with the perl namespace habits. Some of that is applicable to a postgresql package distribution method, but the neat organization is a perl thing, not a CPAN thing, so that idea doesn't really transfer. Or is it because the projects that go into CPAN are better quality and projects in pgroundry? Partly. There are some dubious packages on CPAN but they're finished, and with extremely few exceptions download, pass their self tests and do what it says on the box (the main flaws are packages going stale and occasionally dependency problems). Pgfoundry is a development site with a search engine and has projects in various stages of completion from vaporware to production tested usable code. Or is it something else? Projects vs Packages sums up the differences. Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Apr 2008 12:46:30 -0400 D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008 09:41:57 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Apr 2008 12:35:31 -0400 D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008 13:54:11 - Greg Sabino Mullane [EMAIL PROTECTED] wrote: Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. Pgfoundry is not a kiss of death except that you spread falsehoods like that. PGfoundry is a very alive project that is constantly adding content and has continuing and very active projects. Eep! Careful with attributions. There is not a single word of mine in what you included. I know it technically says that but since your comments were directed at Greg you really should have replied to his email and not to mine that included his. Sorry Darcy :). Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9Qv2ATb/zqfZUUQRAtBCAJ4yRvm6IydAstjb06G2mM8XhkVfPACfdmCy oa3KN6PmkXzZgFlFOSHseVk= =T5sZ -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, 03 Apr 2008 09:31:01 -0700 Ron Mayer [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain wrote: Check out NetBSD pkgsrc as a model. It is very flexible. One nice thing would be the ability to specify where the packages are rather than always insisting that they be on pgfoundry. Yup - a feature shared by RubyGems: gem install rails ?source http://gems.rubyonrails.org Yes but what I am suggesting goes beyond that. My idea is that there is a modules directory that contains a file for each installable module. This file would contain all the information about the module such as name, version, where to get the actual package, an MD5 checksum of the package, minimum and maximum PostgreSQL versions required, etc. Naturally we should allow for people to define their own local packages as well. In fact, this may be the way to deprecate contrib. Start building modules and move the contrib packages to it one at a time. That way people using contrib have some time to switch and we can point people to modules if they are just starting out. Is there support for this idea? I would like to start exploring this if so. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
D'Arcy J.M. Cain wrote: In fact, this may be the way to deprecate contrib. Start building modules and move the contrib packages to it one at a time. That way people using contrib have some time to switch and we can point people to modules if they are just starting out. Is there support for this idea? I would like to start exploring this if so. No. I don't want to deprecate it, I want to get rid of it, lock, stock and barrel. If you think that we need more than renaming then we can discuss it, but I don't want a long death, I want one that is certain and swift. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, 03 Apr 2008 13:06:25 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain wrote: In fact, this may be the way to deprecate contrib. Start building modules and move the contrib packages to it one at a time. That way people using contrib have some time to switch and we can point people to modules if they are just starting out. Is there support for this idea? I would like to start exploring this if so. No. I don't want to deprecate it, I want to get rid of it, lock, stock and barrel. If you think that we need more than renaming then we can discuss it, but I don't want a long death, I want one that is certain and swift. Well, OK, but given that this is a huge public project with lots of users expecting things to be in certain places, how fast do you think we could make such a change. It seems to me that we are going to have to make things look the same for some time at least otherwise we are going to have lots of complaints. How swift is swift? To me, swift means add the alternate functionality to the next release and remove the old in the release after. Do you see things happening any faster? -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, Apr 3, 2008 at 10:36 PM, Andrew Dunstan [EMAIL PROTECTED] wrote: No. I don't want to deprecate it, I want to get rid of it, lock, stock and barrel. If you think that we need more than renaming then we can discuss it, but I don't want a long death, I want one that is certain and swift. I'll admit that I had thought that moving contrib modules over to a modules dir as they were, uh, modularized would be the way forward. Anything that doesn't fit the database-owner-installable pattern (pgbench? start-scripts? others?) could end up in a utils dir, and anything left in contrib shows us what's left to do before e.g. 8.4. The end goal would be no more contrib dir by the next major release. As a side note, how were you intending to rename contrib? Directory shenanigans in CVS are horrible, particularly if you want all your old branches to still work. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Apr 2008 13:27:03 -0400 D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: Well, OK, but given that this is a huge public project with lots of users expecting things to be in certain places, how fast do you think we could make such a change. 8.4. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFH9RY/ATb/zqfZUUQRAu0SAJ9+bnPyHmVIRb/QgbD8plEmGBRC2gCY0uS2 L+stcsM5h97QAzT23VD8zw== =z+FW -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
D'Arcy J.M. Cain wrote: On Thu, 03 Apr 2008 13:06:25 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain wrote: In fact, this may be the way to deprecate contrib. Start building modules and move the contrib packages to it one at a time. That way people using contrib have some time to switch and we can point people to modules if they are just starting out. Is there support for this idea? I would like to start exploring this if so. No. I don't want to deprecate it, I want to get rid of it, lock, stock and barrel. If you think that we need more than renaming then we can discuss it, but I don't want a long death, I want one that is certain and swift. Well, OK, but given that this is a huge public project with lots of users expecting things to be in certain places, how fast do you think we could make such a change. It seems to me that we are going to have to make things look the same for some time at least otherwise we are going to have lots of complaints. How swift is swift? To me, swift means add the alternate functionality to the next release and remove the old in the release after. Do you see things happening any faster? I don't understand this at all. We are talking about directory and package organisation here. How do you do that with transition arrangements? I guess we could put in a symlink from contrib, but I just don't see the point. I don't think we are under any obligation to preserve the way we package or split packages between releases. And doing this reorganisation now, fairly early in the release cycle, would let us give people like packagers plenty of advance notice. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
* Tom Dunstan [EMAIL PROTECTED] [080403 13:30]: As a side note, how were you intending to rename contrib? Directory shenanigans in CVS are horrible, particularly if you want all your old branches to still work. Well, please, anybody doing this, just simply copy and use cvs remove and cvs add... We're using CVS, so we live with disjoint history on renames... As long as the commit comment is clear, the history isn't lost, just another command away. 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
Re: [HACKERS] modules
On Thursday 03 April 2008 08:47:12 Joshua D. Drake wrote:
On Thu, 3 Apr 2008 21:03:05 +0530
Tom Dunstan [EMAIL PROTECTED] wrote:
On Thu, Apr 3, 2008 at 8:25 PM, Andrew Dunstan [EMAIL PROTECTED]
wrote:
If this were at all true we would not not have seen the complaints
from people along the lines of My ISP won't install contrib. But
we have, and quite a number of times. We have concrete evidence
that calling it contrib actually works against us.
It's hard to see ISPs who won't install contrib from installing
${random module} from the big bad internet as has been discussed in
this thread, but who knows?
Sure it is. The very word contrib brings about ideas of things like:
Unstable, Cooker, unofficial.
modules is completely different (from a perception perspective).
IMO the core modules should be compiled via configure with something
like:
./configure --enable-module=ALL
or
./configure --enable-module=pgcrypto --enable-module=cube
This would install all the modules but not enable them in the database
itself (of course). This could also be extended to the pls so that we
have exactly one mechanism to control those options as well.
./configure --enable-module=pgcrypto --enable-module=plperl
I think --enable-module might be the wrong term here, since you specificaly
state we are not enabling them in the database.
I think --with-module=... might be a better way to go.
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
--
Darcy Buskermolen
Command Prompt, Inc.
+1.503.667.4564 X 102
http://www.commandprompt.com/
PostgreSQL solutions since 1997
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Apr 2008 12:03:43 -0700 Darcy Buskermolen [EMAIL PROTECTED] wrote: This would install all the modules but not enable them in the database itself (of course). This could also be extended to the pls so that we have exactly one mechanism to control those options as well. ./configure --enable-module=pgcrypto --enable-module=plperl I think --enable-module might be the wrong term here, since you specificaly state we are not enabling them in the database. I think --with-module=... might be a better way to go. That would work. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9S8HATb/zqfZUUQRAjAFAJ0dsH4Cwr3WuiLXVKw9tReOarhKSQCeNuKL GkaxyLV8eC/YhUzgfd4YTEI= =6C6r -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Joshua D. Drake wrote: On Thu, 3 Apr 2008 13:54:11 - Greg Sabino Mullane [EMAIL PROTECTED] wrote: Right now contrib is a real catch-all of various things; it would be nice to categorize them somehow. And by categorize, I emphatically do NOT mean move to pgfoundry, which is pretty much a kiss of death. Pgfoundry is not a kiss of death except that you spread falsehoods like that. PGfoundry is a very alive project that is constantly adding content and has continuing and very active projects. +1. This modules/packages concept seems 100% orthogonal to pgfoundry to me. Pgfoundry seems like a bug-tracking / development infrastructure somewhat like sourceforge. Some modules might want to use it, some might not (no doubt postgis would stay with refractions, etc). This hypothetical modules project is more focused on installers, and perhaps ways to find and run the module installers whether from pgfoundry or elsewhere. Ron PS: Regarding pgfoundry and credibility; it seems the stature and image of pgfoundry would go up a lot if postgresql itself were hosted there. But no, I'm not advocating that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Thu, 3 Apr 2008, Peter Eisentraut wrote: Am Donnerstag, 3. April 2008 schrieb Andrew Dunstan: If this were at all true we would not not have seen the complaints from people along the lines of My ISP won't install contrib. But we have, and quite a number of times. We have concrete evidence that calling it contrib actually works against us. ISPs also won't install additional Perl modules, for example. Yet, CPAN does exist successfully. ISPs don't necessarily HAVE to install additional perl modules. If I have my own home directory and shell access, I can run perl Makefile.PL PREFIX=/home/myuser/perlstuff, and just tweak PERL5LIB (or use lib) and I can install modules without any superuser intervention. This is where the CPAN comparison breaks down. I can install any perl module I want (native perl or even XS/C modules) without superuser privileges. With postgres, super user privileges are REQUIRED to install any module, whatever it is called (contrib, modules, pgfoundry, gborg)... IMHO, this is the Achilles heel of Postgres extensibility. Look at this library of plugins out there that do all of these nifty things, and if you can't find one that fits your needs, you can always write a little C code to do the job exactly how you want. Too bad you can't use them if you can't afford your own dedicated database server instance... This was the most frustrating thing for me as a developer. I know that there are all of these fine modules out there, and I even have a few of my own. I have been spoiled by the extensibility of Postgres, only to have it taken away when I want to move my databases from my own machine into production on the hosting provider. If I want to put geographical data in a database, I know PostGIS is out there, but I can't install it. I could use cube/earthdistance, but I can't install that either. So much for the geographical data. How about text search? Nope, can't have that either, at least until 8.3 finds its way into OpenBSD ports and the hosting provider gets around to installing it. At least I have that to look forward to. My opinion is, it doesn't matter what you call the modules/contrib stuff if I can't use it, and I can't use it if it is not loaded in my database, and I can't load it without superuser privileges. -- Never put off till tomorrow what you can avoid all together. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Ron Mayer wrote: Andrew Dunstan wrote: Tom Lane wrote: as having better system support for packages or modules or whatever you want to call them; and maybe we also need some marketing-type ...re-raise the question of getting rid of contrib... The PostgreSQL Standard Modules. While renaming, could we go one step further and come up with a clear definition of what it takes for something to qualify as a module? In particular I think standardizing the installation would go a long way to letting packagers automate the installation of modules from pgfoundry. I think it'd be especially cool if one could one-day have a command pg_install_module [modulename] -d [databasename] and it would magically get (or verify that it had) the latest version from pgfoundry; compile it (if needed) and install it in the specified database. The closest analogy to what I'm thinking is the perl CPAN or ruby gems. Yes, and the CPAN analogy that has been in several minds, but it only goes so far. Perl and Ruby are languages - Postgres is a very different animal. We do in fact have some support for building / installing some modules in a standard way. It's called pgxs and it is used by quite a number of existing modules. 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. We don't have a central repository of non-standard modules, like CPAN, and so of course no facility for fetching / building / installing them. Not all modules fit a single pattern, either. There are addon languages, types, and function libraries, as we all as utilities that are not installed in the database at all. Finally, setting up modules so they can be built for Windows, especially using MSVC, will probably be quite a challenge. So if someone wants to make a start on any of this I'm sure we would all listen up. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
Andrew Dunstan wrote: I think it'd be especially cool if one could one-day have a command pg_install_module [modulename] -d [databasename] Yes, and the CPAN analogy that has been in several minds, but it only goes so far. Perl and Ruby are languages - Postgres is a very different animal. Sure - but the benefits of standardizing installers for optional components seems to apply the same for both. We do in fact have some support for building / installing some modules in a standard way. It's called pgxs and it is used by quite a number of existing modules. Cool. Seems to handle at least quite a bit of the building part of standardized modules. 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. I'm guessing that this would be harder to add various options (install/ignore dependancies ; specify a different source web site) that a standard installer would like to have. We don't have a central repository of non-standard modules, like CPAN, and so of course no facility for fetching / building / installing them. Seems that could easily be improved in a number of ways. * The installer could specify the source. For example pg_install_module postgis -source http://www.refractions.net in exactly the same way ruby uses gem install rails –source http://gems.rubyonrails.org * pgfoundry could provide a repository of installable modules for projects hosted there. * perhaps pgfoundry could even have a section where it points to installers on third party sites? Not all modules fit a single pattern, either. There are addon languages, types, and function libraries, as we all as utilities that are not installed in the database at all. Agreed. Such a mechanism would only really apply for things that are installed in the database. But from an end user's point of view, installing functions, index types, languages, data types, etc all see to fit the pg_install postgis -d mydb, pg_install pl_ruby -d mydb, etc. pattern pretty well. Finally, setting up modules so they can be built for Windows, especially using MSVC, will probably be quite a challenge. Indeed. Seems ruby gems give you the option of installing a ruby version or a windows version that I'm guessing has pre-compiled object files. So if someone wants to make a start on any of this I'm sure we would all listen up. I'm happy to try, though might need pointing in the right directions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] modules
On Wed, 02 Apr 2008 20:15:49 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: I think it'd be especially cool if one could one-day have a command pg_install_module [modulename] -d [databasename] and it would magically get (or verify that it had) the latest version from pgfoundry; compile it (if needed) and install it in the specified database. The closest analogy to what I'm thinking is the perl CPAN or ruby gems. Check out NetBSD pkgsrc as a model. It is very flexible. One nice thing would be the ability to specify where the packages are rather than always insisting that they be on pgfoundry. Yes, and the CPAN analogy that has been in several minds, but it only goes so far. Perl and Ruby are languages - Postgres is a very different animal. So the underlying struture needs to keep that in mind. Overall though I don't think that what is being installed to changes much. The basics remain the same - define the package with latest version, download if necessary,check that the source package is the correct, tested one, build, install, register. There are some special considerations for PostgreSQL but I think that the fact that there are unsolved problems shouldn't stop us from solving them. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
