Re: pg_migrator issue with contrib - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_migrator issue with contrib
Date
Msg-id 1890.1244487677@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_migrator issue with contrib  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_migrator issue with contrib  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> 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".

> Sure, pg_migrator is good at checking.  Please confirm you want this
> added to pg_migrator.

Yeah, I'd suggest it.  Even if we later come up with a workaround for
contrib/isn, you're going to want to have the infrastructure in place
for this type of check, because there will surely be cases that need it.

Note that I think the FLOAT8PASSYVAL check is a must.  There is no
reason to forbid migrating isn on 32-bit machines, for example.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_migrator issue with contrib
Next
From: Bruce Momjian
Date:
Subject: Re: pg_migrator issue with contrib