Re: Remove lossy-operator RECHECK flag?

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!

In response to

Responses

Browse pgsql-hackers by date

  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