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

From Teodor Sigaev
Subject Re: Remove lossy-operator RECHECK flag?
Date
Msg-id 47FFA6DD.6020408@sigaev.ru
Whole thread Raw
In response to Remove lossy-operator RECHECK flag?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove lossy-operator RECHECK flag?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> I can think of is that it'd break user-defined opclasses ... but it's
> not like we don't change the API for GIST/GIN support functions from
> time to time anyway.  Does anyone have any idea how many people are
Hmm. The biggest breakage of interface to indexes was a removing 
pg_am.amconcurrent flag - there is one or two implementation of indexes which 
was depending of this flag. All our modules related to GIN or GiST  are in 
contrib already, new wildspeed will not work with <=8.3 version anyway.

> building custom opclasses containing lossy operators?  Offhand I suspect
> only the PostGIS project would be affected.
Yes, I think so.

> 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.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Cached Query Plans
Next
From: "Dickson dos Santos Guedes"
Date:
Subject: Patch to add objetct size on "\d+" verbose output