Re: Extension Templates S03E11

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Templates S03E11
Date: 2013-12-05 05:39:56
Message-ID: 1386221996.19125.280.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Muraviov 2013-12-05 06:09:47 Re: Problem with displaying "wide" tables in psql
Previous Message Tom Lane 2013-12-05 05:30:22 Re: Performance optimization of btree binary search