Re: Remove lossy-operator RECHECK flag?

From: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Teodor Sigaev" <teodor(at)sigaev(dot)ru>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remove lossy-operator RECHECK flag?
Date: 2008-04-11 19:33:26
Message-ID: 1d4e0c10804111233t4bf23b5bw5f777edeb74722eb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 11, 2008 at 9:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> To be blunt, that seems like a really bad idea, and I have not the
> slightest hesitation about breaking your ability to do it. How
> do you know that the recheck-need corresponds to what you are testing
> on the application side?

From what I read when I did that a few months ago, the recheck was
added to provide SRID checking.
If you don't have it, you don't have the SRID mismatch error when
SRIDs don't match.

> If there's actually some safe, consistent use for such behavior
> then I think you need to lobby the PostGIS project to provide
> access to it.

In the general case, there isn't. If you enforce the SRID (using a
wrapper/constraints/whatever), there is.

After some googling, I finally found the post of Mark Cave-Ayland on
postgis-users which made me take this decision:
http://www.mail-archive.com/postgis-users(at)postgis(dot)refractions(dot)net/msg01206.html

Don't know if there is a better way to do it in PostGIS itself but the
ability to take this decision for a specific database (or even column)
is really convenient.

--
Guillaume

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-04-11 19:33:56 Re: Commit fest status
Previous Message Bruce Momjian 2008-04-11 19:18:16 Re: Commit fest status