Oops, sent with wrong from header...
---------- Forwarded message ---------- From: "Tom Dunstan" <[EMAIL PROTECTED]> To: "Dimitri Fontaine" <[EMAIL PROTECTED]> Date: Wed, 23 Jul 2008 19:40:30 -0400 Subject: Re: [HACKERS] PostgreSQL extensions packaging Hi! On Wed, Jul 23, 2008 at 5:08 PM, Dimitri Fontaine <[EMAIL PROTECTED]> wrote: > I promised to have an in-depth look at the archives before to spend time on > my ideas for $subject, but failed to do so. I guess that means you missed both the original discussion at http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php and my initial patch in that direction and subsequent discussion at http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php then :(. There were two core components to my idea of modules/packages: - Separation of installation at an OS level (RPM/yum, deb/dpkg, MSI installer etc) and installation into a database. The intention was a) to standardize package installation generally so that users didn't have to read n different sets of installation instructions for n different packages, and b) so that a db owner could install into their own database any module that had been installed on the system, even if that might include e.g. C functions that they otherwise would not be able to install without being a superuser. - Have dependency tracking so that pg_dump could emit e.g. "LOAD MODULE foo;" rather than all the different instructions to recreate the module. So the proposed installation procedure would be more along the lines of: yum install postgresql-module-postgis echo "load module postgis" | psql mydb My intention was to use whatever native package manager was appropriate for your distro rather than trying to recreate CPAN, although some people in the original discussion wanted to go down that route. The patch that I provided didn't do any of the dependency stuff yet - I had been investigating various ways to do it automagically, although I haven't worked on it for a little while. It may be that the straight forward explicit declaration that you have here is a better way to do it. I didn't have versioning and interdependencies between modules yet, although it's an obvious extension to the idea. > A package can also host variables, which visibility are > package global: any SQL into the package can refer directly to package > variables. That was way out of scope for my more modest suggestion - I certainly wasn't going to change pl/pgsql semantics. For example, how do those variables behave upon a transaction rollback? > Now, what would be really good to have would be this pg_pkg command I was > dreaming about in another -hacker mail: This turns into recreating CPAN. I like the idea of a "blessed" set of packages, but would rather not require all postgresql users to have a full build environment (especially on windows) and have to replace their native packaging solution. It seems that you agree that fetching/installing should be separate from loading/installing into the database. Good. Some posters on the original thread were suggesting that the fetch/install step should somehow do the database installation as well, which sounded like a huge can of worms. I think that we can come up with a package/module format that allows installation at the OS level without demanding a whole set of download / build machinery. If someone then wants to build that and have it install packages, then fine, but we definitely should not require it to be able to install stuff. Look forward to your comments 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
