Re: Remove lossy-operator RECHECK flag? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove lossy-operator RECHECK flag?
Date
Msg-id 19212.1208122532@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove lossy-operator RECHECK flag?  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: Remove lossy-operator RECHECK flag?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> 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


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Commit fest queue
Next
From: "Dickson dos Santos Guedes"
Date:
Subject: Re: Patch to add objetct size on "\d+" verbose output