Itagaki Takahiro <itagaki.takahiro@gmail.com> writes:
> The latest extension might drop some functions.
Then the upgrade script contains the DROP commands.
> I'm still not clear what "upgrade" means. if module authors wrote
> functions with C, they can just replace .so to upgrade. If with
> SQL or PL/pgSQL, they should execute CREATE OR REPLACE FUNCTION.
When do you execute those statements? Certainly, you want the user to
issue ALTER EXTENSION foo UPGRADE and be done with it.
> The patch seems useful to upgrade from NULL to 1.0, but I cannot
> imagine how it work for cases from 1.0 to higher versions.
> For example, if we have 3 versions of a module below:
> NULL unmanaged functions only
> v1 EXTENSION support with an additional function
> v2 EXTENSION support with another function.
> How do we write upgrading scripts for NULL=>v1, NULL=>v2, and v1=>v2 ?
Well, you write 3 scripts.
Let's consider an example, the lo contrib, with its 3 objects:
CREATE DOMAIN lo AS pg_catalog.oid; CREATE OR REPLACE FUNCTION lo_oid(lo) … CREATE OR REPLACE FUNCTION lo_manage() …
Now, the upgrade script from version NULL to 1.0 is
alter domain @extschema@.lo set extension lo; alter function @extschema@.lo_oid(lo) set extension lo; alter function
@extschema@.lo_manage()set extension lo;
The upgrade script from version 1.0 to 2.0 is, let's say:
CREATE OR REPLACE FUNCTION @extschema@.lo_newfunc() …
So the upgrade script from version NULL to 2.0 is:
alter domain @extschema@.lo set extension lo; alter function @extschema@.lo_oid(lo) set extension lo; alter function
@extschema@.lo_manage()set extension lo; CREATE OR REPLACE FUNCTION @extschema@.lo_newfunc() …
If as an extension author you're kind enough to provide all those 3
scripts and the upgrade setup in the control file, then the user can
issue ALTER EXTENSION lo UPGRADE; and have all your cases covered
automatically.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
