Re: pg_migrator issue with contrib

I wrote:
> [ concerning various migration hazards in contrib/ ]

> * isn has got the nastiest problems of the lot: since it piggybacks
> on type bigint, a migrated database might work, or might crash
> miserably, depending on whether bigint has become pass-by-value
> in the new database. I'm not very sure if we can fix this reasonably.

I've spent some time thinking about possible workarounds for this, and
not really come up with any. The only feasible thing I can think of
to do is teach pg_migrator to refuse to migrate if (a) the old DB
contains contrib/isn, and (b) the new DB has FLOAT8PASSYVAL (which
can be checked in pg_control). One question here is how you decide
if the old DB contains contrib/isn. I don't think looking for the
type name per se is a hot idea. The best plan that has come to mind
is to look through pg_proc to see if there are any C-language functions
that reference "$libdir/isn".

> * pg_freespacemap has made *major* changes in its ABI. There's
> probably no hope of this working either, but we need to be sure
> it's not a crash risk.

This turns out not to be a problem: the set of exposed C function names
changed, so the function definitions will fail to migrate. Dropping
the module before migrating and reinstalling it afterwards is an easy
workaround.

> * pgstattuple has made changes in the output types of its functions.
> This is a serious crash risk, and I'm not immediately sure how to
> fix it. Note that simply migrating the module will not draw any
> errors.

This doesn't seem to create serious problems either. pgstatindex() has
changed some output columns from int4 to int8, but because it creates
the result tuple from text strings, it manages to just work anyway.
(In principle you could get some overflow problems with very large
indexes, but I doubt that's an issue in practice; and it couldn't cause
a crash anyway.) pg_relpages() likewise changed its return type, but
in this particular case you could only get garbage answers not a crash.
So I think we can just tell people to reinstall the SQL file after
migration.

> * tsearch2 has opclass support function changes, but unlike other
> cases of this, it will fail to migrate to 8.4 because the functions
> are references to core functions instead of being declared in the
> module. Also, "drop it first" isn't a very useful recommendation
> since the domains it defines might be used somewhere.

It would be nice if this migrated cleanly, but it doesn't and there's
not much we can do about it. At least it will fail safely.

So, other than the suggested pg_migrator hack for contrib/isn, the only
thing left to do here is fix dblink_current_query(). I'll take care of
that, but not till after Joe commits his remaining patch, so as not to
risk creating merge hazards for him.

regards, tom lane