Re: ALTER EXTENSION UPGRADE, v3

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-11 16:22:24
Message-ID: m28vxmczi7.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> CREATE EXTENSION foo [ VERSION targetversion ] [ FROM
oldversion ]

I came to the same conclusion but added my version aliases idea in
there so that it could maybe be easy for the user not to confuse
things.

I still think that free form version aliases and some defaults
used by the core code is a very interesting feature to have, but I
can see that it's not required for the feature to fully work.

> 1. If you pick the wrong FROM version, the upgrade script will
> almost certainly fail, because the objects won't exist or won't
> be in the state it expects (ie, not already members of the
> extension).

Is there a test somewhere that when CREATE OR REPLACE FUNCTION
runs from an extension's script at upgrade, the function must
already be attached to the extension if it exists in the system?
Ditto for views etc?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2011-02-11 16:22:57 Re: pl/python tracebacks
Previous Message Steve Singer 2011-02-11 16:22:17 Re: pl/python explicit subtransactions