documentation and clearifying of ~= change

[nicklas]

The change #282 in behavior of ~= operator from working as a fast variant of st_OrderingEqual to just comparing bboxes is not documentated.

This was a result from discussions in #253

I don't know those different index approaches enough to understand this.

What is now the diffeence between operator = and ~=

Why use && in ST_Equals and new ~= in ST_OrderingEquals

Maybe should have been more tickets, but I don't know what here is valid questions.

/Nicklas

[pramsey]

I'm deferring this, since I hate all operators except && and can't believe anyone uses them. I think we have problems fundamentally with the '=' operator, since people have such strong internalized notions of what it means. BTW, the difference between = and ~= is what opclass they are defined for. = is defined on the btree and ~= on the gist index.

[robe]

The difference is that = doesn't use an index and ~= uses an index. Except for the rare case if you put a btree index on a geometry which you can only do for small thngs like points.

Am I safe in saying that we can never make = use a gist index as I assume since a gist is marked as lossy, it would never be able to be used in group by, order by etc. Perhaps Paul, Mark or Kevin can confirm my understanding of this.

Ideally we would just use = and scrap ~=, but we can't because we need a fast bounding box check. Huh Paul yap I am and I think Kevin too are those unbelievable people you talk about. ~= is important (well an indexable bounding box equality operator)

[nicklas]

I will try to come up with some rough doc before final release of 1.5.0
Now the doc gives wrong information, and I guess some poor information is better than wrong information.

The problem I think is that ~= was that much faster solution than ST_OrderingEquals in 1.4 and below. Because of that it might be quite commonly used.

And the difference between bounding box comparation and geometry_same will not show in majority of situations but might be a very important difference in others.

[robe]

Nicklas,

I'll take that as a volunteer from you it shove it over to you. Hmm this is beginning to feel like musical chairs.

Probably worthwhile noting that since the operator can't be dropped, if you soft upgraded from PostGIS 1.3 and never did a hard upgrade ~= still behaves like an exact geometry operator and if you soft-upgraded. If your first version of PostGIS was 1.4.0 then it behaves like a bbox operator, but if you soft-upgraded from 1.4.1 (that being your first version or did a hard upgrade, then it behaves like a geometry equality operator).

[nicklas]

ok, this seems to be more messy than I suspected.

I will give it a try but I can't until tomorrow evening so don't wait for it with RC1.

I guess the most important information to give in doc is "Stay away, don't use it, because the behavior is more unpredictable than coming weather" but maybe in other words

[robe]

Yap that sounds like a good description — use ST_OrderingEquals instead

[nicklas]

Here comes a suggested text for doc of ~= operator, attached as patch.

I haven't successed to get the dependencies in place to make the documentation, so I didn't want to commit it when I haven't seen the result.

/Nicklas

[robe]

Nicklas,

Just commit it. I'm not setup to build the documentation either. I just wait for hudson to complain if there are issues and also use my trusty xml error checker in my JEdit IDE. It won't break anything on the site if you have mistakes, just won't build a new PDF file or html document if it has errors which is not a big deal.

[nicklas]

Ok, I have committed at r5161.

But I missed to comment the commit What to do then?

/Nicklas

[robe]

I don't think our SVN settings allow back commenting, since I tried and got a repository's pre-revprop-change hook failed or is non-existent. I think I've gotten that same error before when trying to change my own comments.

Anyrate we'll survive somehow with this missing comment.

The doc looks fine to me so closing this out.