Tom Lane wrote: > 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".
Sure, pg_migrator is good at checking. Please confirm you want this added to pg_migrator. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers