Re: latest hstore patch

>>>>> "Bruce" == Bruce Momjian <bruce(at)momjian(dot)us> writes:

>> There's still the issue of how to get the improved module
>> definition (new functions etc) into a migrated database. That's
>> not specific to hstore in any way though, it would affect any
>> contrib module that had added stuff in a new release.

Bruce> Most modules just install functions, which are easily
Bruce> uninstalled/reinstalled. A data type like hstore is more
Bruce> complicated assuming it is the data type that is changing and
Bruce> not the support functions.

For hstore, the various changes (and their solutions if any) are roughly
these:

1) new functions and operators - these don't present a migration issue
other than that they won't be available in a migrated db unless added,
which can be done after the fact with CREATE FUNCTION / CREATE OPERATOR
as in the install script. (This issue is the same for dump/restore
upgrades if the new version is not installed prior to the restore)

2) new internal C names for some functions - this is addressed in hstore
by defining both the new and old names, so no migration issue there
(running an after the fact CREATE OR REPLACE FUNCTION, as in the install
script, will remove the references to the old names; but even that much
isn't necessary unless there's actually a naming conflict)

3) Change in the representation of the underlying data. This is handled
by having the code recognize the old format and convert it on the fly;
this isn't ideal, but it does work.

4) Change in the SQL-level definition of the data type (specifically,
the new code adds SEND and RECEIVE functions which weren't previously
present). This is a hard one; currently, even for a dump/restore
upgrade, this requires that you run the new version's .sql file before
restoring the dump, otherwise you get the old type definition with
those functions missing, and there's no convenient way to add them
back. A migration upgrade would have the same issue.

5) Changes to operator classes; the new version adds two new
opclasses, which is easy, but it also adds new operators to two
opclasses defined in the old version, and there's no ALTER or CREATE
OR REPLACE for those. Again, with a dump/restore upgrade this is
fixable by installing the new version before restoring; if you don't
do that, there's no convenient way to enable access to the new
functionality short of dropping the old opclasses (and all the indexes
that use them) and recreating them.

It's really items (4) and (5) (and similar ones, such as changes to
operator definitions, and other SQL-level objects that don't have an
OR REPLACE option) that currently present an obstacle for all module
authors. (3) is something that's more of a case-by-case problem which
can be tackled within the module itself.

--
Andrew.