From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_migrator issue with contrib |
Date: | 2009-06-08 19:01:17 |
Message-ID: | 1890.1244487677@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-06-08 19:02:56 | Re: pg_migrator issue with contrib |
Previous Message | Bruce Momjian | 2009-06-08 18:57:11 | Re: pg_migrator issue with contrib |