Re: Extension Packaging
Aidan Van Dyk <aidan@highrise.ca>
From: Aidan Van Dyk <aidan@highrise.ca>
To: "David E. Wheeler" <david@kineticode.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Daniele Varrazzo <daniele.varrazzo@gmail.com>, "pgsql-hackers@postgresql.org Hackers" <pgsql-hackers@postgresql.org>
Date: 2011-04-25T16:14:32Z
Lists: pgsql-hackers
On Mon, Apr 25, 2011 at 12:00 PM, David E. Wheeler <david@kineticode.com> wrote: > These are really great points. I knew I wasn't thrilled about this suggest, but wasn't sure why. Frankly, I think it will be really confusing to users who think they have FooBar 1.2.2 installed but see only 1.2 in the database. I don't think I would do that, personally. I'm much more inclined to have the same extension version everywhere I can. Really, that means you just a sql function to your extension, somethign similary to uname -a, or rpm -qi, which includes something that is *forced* to change the postgresql catalog view of your extension every time you ship a new version (major, or patch), and then you get the exact version (and whatever else you include) for free every time you update ;-) The thing to remember is that the postgresql "extensions" are managing the *postgresql catalogs* view of things, even though the shared object used by postgresql to provide the particular catalog's requirements can be "fixed". If your extension is almost exclusively a shared object, and the only catalog things are a couple of functions defined to point into the C code, there really isn't anything catalog-wise that you need to "manage" for upgrades. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.