From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Teodor Sigaev" <teodor(at)sigaev(dot)ru>, "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove lossy-operator RECHECK flag? |
Date: | 2008-04-14 20:16:45 |
Message-ID: | 87ve2kfaz6.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> Anybody else have an opinion?
>
> Better slow than wrong in this case.
>
> The "better to break obviously than subtly" argument doesn't hold here, because
> "slow" isn't the same as broken, and returning extra incorrect rows isn't
> "obviously" :-).
We're talking about code which is recompiled for a new version of Postgres but
not altered to return the recheck flag for every tuple? Can we rig the code so
it effectively returns recheck=true all the time in that case? If so then it
would be safe to ignore the recheck flag on the opclass.
There's no danger of picking up code which was actually compiled with older
header files after all, the magic numbers wouldn't match if it's V1 and in any
case I would expect it to crash long before any mistaken tuples were returned.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2008-04-14 20:22:04 | Re: Lessons from commit fest |
Previous Message | Gregory Stark | 2008-04-14 20:12:59 | Re: Lessons from commit fest |