autocast to box causing issues with removed functions

[robe]

Bruce Rindahl pointed out to me that he was in the habit of using the

area function and when he upgraded to 2.0, he could still use the area function, but it was now returning a different answer from ST_Area. I think the wrong answer. I did a test myself on a pure 2.0 install, and came up with the same disturbing answer. Seems our geometries are falling into the built in box type is my guess and enjoying te fruits of using box area functions.

Demonstration:

select st_area(ST_Buffer(ST_MakeEnvelope(1,2,3,4),1)) As our_area,
area(ST_Buffer(ST_MakeEnvelope(1,2,3,4),1)) As our_geom_found_in_box,
area(ST_Buffer(ST_MakeEnvelope(1,2,3,4),1)) As explicit_cast_box

All kinda disturbing:

     our_area     | our_geom_found_in_box | explicit_cast_box
------------------+-----------------------+-------------------
 15.1214451522581 |                    16 |                16

I suppose we could just bring back area and length to prevent this from happening. I suspect those might be the only two.

[brindahl]

st_centroid vs center might also be confusing. st_centroid returns a geometry while center returns a PostgeSQL point type so that part is obvious but the x and y coordinates are different. Testing length but there seems to be multiple versions of the function in PostgreSQL

[robe]

I forgot about the more obvious solution though I guess we can't do it until 2.1 since its an API change. Can simply change this cast from IMPLICIT to assignment?

So if we do this:

CREATE CAST (geometry AS box) WITH FUNCTION box(geometry) AS IMPLICIT;

to

CREATE CAST (geometry AS box) WITH FUNCTION box(geometry) AS ASSIGNMENT;

I experimented with dropping it and as far as I can tell the earth did not shatter (it let me drop without complaining it needed to drop anything)

It might break some people's code, but it was problem breaking people's code already in the worst possible way: LOGICAL.

Once I made that change on my db, then this:

SELECT area('POINT(1 2)'::geometry)

was no longer legal and gave the correct

ERROR:  function area(geometry) does not exist
LINE 1: SELECT area('POINT(1 2)'::geometry)

Of course this means putting in

ALTER EXTENSION postgis DROP CAST (geometry AS box);  -- only needed for extension
DROP CAST (geometry AS box);
CREATE CAST (geometry AS box) WITH FUNCTION public.box(geometry) AS ASSIGNMENT;

[robe]

I meant

CREATE CAST (geometry AS box) WITH FUNCTION box(geometry) AS ASSIGNMENT;

or we could get rid of it, though I am tempted to say NO for that just because in 2.1 now that we allow casting from PostgreSQL types it only seems fair to allow casting back.

[robe]

okay I converted to assignment at: r11340

but haven't put in upgrade logic. I hate repeating the CAST twice and don't see any other way for upgrade since our upgrade perl script strips out CREATE CAST from postgis.sql.in

[robe]

The ideal would be to just drop the CAST entirely but not sure it exists for a reason. As far as I can tell its not tied to anything. The I can just put the drop cast in our drop after section.

[robe]

pramsey et. al,

thoughts on this or are we fine that its a non-issue for people doing a hard-upgrade or new upgrade, but minor upgrades will suffer the same old behavior.

I guess it's not a super big deal or we can push the issue to a micro release at another time.

[pramsey]

I am happy with changing away from using an implicit cast.