Re: ALTER EXTENSION UPGRADE patch v1

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: David Fetter <david(at)fetter(dot)org>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER EXTENSION UPGRADE patch v1
Date: 2011-01-05 19:15:47
Message-ID: m2d3obkvq4.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> The syntax by itself does nothing, but the underlying capability gives
> users:

Ok, now I understand that the syntax you proposed was a shortcut for an
I-want-it-all request :)

> - The ability to have versions of software on different databases on
> the same system.
>
> - The ability to do deterministic upgrades, rather than just, "upgrade
> me to the latest, which may be buggy and/or slow things down to
> avoid a problem I know I don't have."

Both depends on a filesystem organization rework.

> I am not saying that this is a show-stopper. I *am* saying that
> multiple concurrent versions and deterministic upgrades are common
> enough requests that you shouldn't do things that would prevent those
> in the future.

Would it be useful to have the syntax support in 9.1 already, but which
would only check that the asked-of new version (and current version) are
the one currently available (and installed), and ERROR out otherwise?

I think that syntax-and-check is still doable for 9.1, if there's a will
to get there.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2011-01-05 19:27:10 Re: We need to log aborted autovacuums
Previous Message Robert Haas 2011-01-05 19:15:28 Re: making an unlogged table logged