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
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 |