From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Remove lossy-operator RECHECK flag? |
Date: | 2008-04-11 17:58:53 |
Message-ID: | 47FFA6DD.6020408@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2008-04-11 18:04:51 | Re: Remove lossy-operator RECHECK flag? |
Previous Message | Gregory Stark | 2008-04-11 17:57:48 | Re: Cached Query Plans |