On Feb 8, 2011, at 9:36 AM, Robert Haas wrote:

I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
UPGRADE is pretty much a must-have for a useful feature regardless of
this issue. I had previously thought that we might be able to limp
along with half a feature for one release - if you're not actually
depending on anything in the extension, you could always drop it and
the install the new version. But the more I think about it, the less
realistic that sounds; dependencies on the extension are going to be
very common, and while it may be practical to drop and recreate the
dependent objects in some cases, it's certainly going to annoy a lot
of people.
I was just thinking about the upgrade issue, and was wondering if this was do-able:

* No upgrade scripts. Nothing to concatenate, include, or maintain.
* No version tracking

Yeah, what I'm saying is, throw out the whole thing. Instead, what would happen is


Would do some trickery behind the scenes to just delete all those objects that are part of the extension (just like DROP EXTENSION should do), and then run the installation SQL script. So the objects would be exactly as specified in the installation script, with no need for the extension maintainer to worry about how to run upgrades, and no need for PostgreSQL to track version numbers.

Is this do-able? I recognize that there could be some issues with settings tables and what-not, but surely that's no different than for dump and reload. The question in my mind is whether it would even be possible for the extension code to unload every bit of an extension and load the new stuff, inside a transaction.




Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 33 | next ›
Discussion Overview
grouppgsql-hackers @
postedFeb 8, '11 at 4:54p
activeFeb 10, '11 at 4:59p



site design / logo © 2023 Grokbase