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: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
