Remove lossy-operator RECHECK flag?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Remove lossy-operator RECHECK flag?
Date: 2008-04-11 17:41:16
Message-ID: 13936.1207935676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ Changing subject to draw people's attention ... ]

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. Does anyone have any idea how many people are
building custom opclasses containing lossy operators? Offhand I suspect
only the PostGIS project would be affected.

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.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-04-11 17:45:08 Re: Cached Query Plans (was: global prepared statements)
Previous Message Tom Lane 2008-04-11 17:31:19 Re: Index AM change proposals, redux