I've been experimenting with dump/reload of 9.0 contrib-using databases
into 9.1 and then applying CREATE EXTENSION FROM to update the contrib
modules to extension style. There are some cases that fail :-(. Most
of them are caused by the GIN extractQuery API changes. In particular,
a 9.0 dump including intarray will fail altogether with
"ginarrayextract(anyarray, internal) does not exist", and similarly
reloading tsearch2 fails with "gin_extract_tsvector(pg_catalog.tsvector,
internal) does not exist". The functions do still exist in core, but we
added an extra argument to each.
There seem to be two possible solutions to this:
1. We could just revert the pg_proc.h changes so that these two
functions are still shown as taking only 2 arguments. Since GIN doesn't
actually look at the signature claimed in pg_proc, this won't break
anything functionally. It's pretty ugly though, and potentially will
confuse people down the road.
2. We could add extra pg_proc.h entries matching the old signatures.
For the moment these would be stub functions that call the same C code,
though eventually perhaps they could be changed to throw errors.
Preferences anyone?
A related issue is that we similarly changed the signatures of GIN
support functions that properly belong to intarray and tsearch2.
That affects what the "unpackaged" conversion scripts need to expect.
What I'm inclined to do there is just change the scripts to absorb
the old functions as-is without trying to correct their signatures.
Doing otherwise is a bit painful because they are operator class
members, and there's no easy way to unhook them from the opclasses
without dropping the opclasses. The only other fix I can think of
is a direct UPDATE on pg_proc to fix the proargtypes entries, which
would work but seems even uglier.
There are some similar issues in pg_trgm as well. I believe we can fix
these with the available facilities so long as we don't mind the fact
that opclasses upgraded from 9.0 installations will be subtly different
from ones installed fresh in 9.1, for example the new operators being
considered "loose" in the opfamily instead of being bound into an
operator class. While I don't immediately see any problems likely to
arise from that, it's something that could perhaps bite us eventually.
But there's no other answer except embarking on a project to materially
upgrade the capabilities of ALTER OPERATOR CLASS/FAMILY, something I
really don't want to be doing right now.
Comments?
BTW, none of these issues are new with the extensions patch; they are
things we broke awhile ago. I'm thinking it's really past time that
we set up some routine buildfarm-style testing to see if pg_upgrade
from the previous version still works.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
