Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> If we do this, should we remove RECHECK from the CREATE OPERATOR CLASS
>> syntax altogether, or leave it in but treat it as a no-op (probably
>> with a warning)?
> I think, it should be a error, but not a syntax error - hint should point to
> use
> new version of module. Loading dump from previous versions with opclass
> definitions is not good action anyway.
Here's a related issue: what should 8.4 pg_dump do when dumping from an
older server version? Some possibilities include
1. Dump the CREATE OPERATOR CLASS command with a RECHECK phrase, same as
before. Then the dump would still work with 8.3 ... at least until we
make some other incompatible change ... while giving an error if loaded
into 8.4.
2. Silently ignore amopreqcheck in older servers. Then the dump would
not load correctly into the older server (but then again, it might
not've anyway). It *would* load into 8.4, but whether it would work
would of course depend on the opclass support functions having been
updated.
3. Throw an error and refuse to dump if it finds amopreqcheck true.
#3 seems just about useless behavior, though. For the moment I have
it doing #1, but it strikes me that that is only useful if 8.4 gets
to release without having made any backwards-incompatible changes in
pg_dump output, which is probably not better than a fifty-fifty bet.
Maybe we should do #2? Thoughts?
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
