On Wed, 2013-12-04 at 15:28 -0500, Robert Haas wrote:
> My experience with software upgrades is that
> cases like this, and even weirder things, happen pretty routinely, so
> I think more control is good.
There would still be control: just use full SQL scripts appropriately.
I'm sure there's still room for surprise as extensions become more
complex. But ultimately, those surprises will happen because of broken
upgrade/downgrade scripts, and if those are broken, the user is probably
in for a surprise in the near future anyway.
It's fine with me if we help alleviate these problems by using a proper
system to organize these upgrades/downgrades. But everything proposed
seems pretty bad from the perspective of an extension author -- extra
documentation, extra ceremony, more room for error, and more maintenance
every time they release a new version. And once we document it, we have
to support those behaviors for a long time, which will almost certainly
prevent a better solution later.
I think we should just make it simple:
* If there is a full SQL script of the given version, we guarantee that
we'll execute that one.
* Otherwise, we execute the shortest path from a full version to the
requested version.
* If there's a tie, throw an error.
That leaves us with plenty of room to improve the situation later, for
instance if we support ordered versions. (I'm not sure if ordered
versions was rejected outright, or we just didn't have time to do it
properly.)
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
