From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Remove lossy-operator RECHECK flag? |
Date: | 2008-04-11 17:55:32 |
Message-ID: | 47FFA614.5080803@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>> RECHECK flag could be removed.
>
> Hmm, that's slightly more radical than I was considering, but it would
> simplify matters wouldn't it? The only strong argument against it that
> 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.
Don't we need to change the GiST/GIN support function interface anyway,
to be able to return the "recheck" flag?
> 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)? The latter would make it a shade easier to load
> existing dumps, but I'm inclined to think if we're going to break
> something it'd be better to break it obviously than subtly.
I agree with rather breaking it obviously than subtly.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-04-11 17:57:22 | Re: Commit fest queue |
Previous Message | Tom Lane | 2008-04-11 17:54:46 | Re: Commit fest queue |