Over a year ago we left it unresolved exactly what to do with
the now-obsolete RECHECK markings in GIST/GIN opclass definitions:
http://archives.postgresql.org/message-id/19212.1208122...@sss.pgh.pa.us
The current behavior of CVS HEAD is more or less designed to
intentionally fail in this case, and it's time to stop doing that.
The question came up again in bug #4817
http://archives.postgresql.org/pgsql-bugs/2009-05/msg00217.php
and I also note that there is zero chance of pg_migrator working
on databases containing lossy GIST/GIN opclasses as things stand.
I think that the right solution is simply to reduce the existing gram.y
ERROR about RECHECK to a WARNING or even a NOTICE; that is, we can just
have 8.4 ignore it and no great harm will be done. Here are the
considerations leading me to that:
1. As I noted in the bug #4817 thread, having pg_dump not emit RECHECK
when scanning an old database seems like a very nasty form of foot-gun.
We can't prevent people from trying to use a newer pg_dump with an older
server.
2. There's also the problem that dumps made with 8.3 or older pg_dump
would contain these keywords even if we had 8.4 pg_dump not emit them.
So we have a forward-porting problem anyway.
3. As things have settled out, there is really not much harm in loading
a pre-8.4 GIST or GIN opclass definition into 8.4. The APIs for some of
the support functions have changed, but in an upward-compatible way.
Even if your underlying .so module knows about the new arguments, it
will still work if the SQL-level function definitions for it don't
include those arguments, because GIST/GIN don't check the SQL-level
function definitions. (Which might be a bad idea overall, but right now
it provides a handy escape hatch.) Certainly, whether the RECHECK flags
mean anything is the very least of your worries about whether an old
opclass will behave correctly in 8.4 --- so it's pretty silly to throw
errors for them when we're not even looking at the support function
signatures.
So it appears to me that downgrading the ERROR is a simple and safe
solution. Any objections?
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
