>>>>> "Bruce" == Bruce Momjian <br...@momjian.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
