[postgis-tickets] [PostGIS] #3031: "POINT EMPTY" as WKB defaults to "MULTIPOINT EMPTY" when restoring with copy and failing validation

[PostGIS]

#3031: "POINT EMPTY" as WKB defaults to "MULTIPOINT EMPTY" when restoring with
copy and failing validation
--------------------------------------------+-------------------------------
 Reporter:  jeanchristophesaville           |       Owner:  pramsey      
     Type:  defect                          |      Status:  new          
 Priority:  medium                          |   Milestone:  PostGIS 2.1.6
Component:  postgis                         |     Version:  2.1.x        
 Keywords:  POINT EMPTY , MULTIPOINT EMPTY  |  
--------------------------------------------+-------------------------------

Comment(by robe):

 I looked at the regress and your failures here:

 http://debbie.postgis.net:8080/job/PostGIS_Regress/5936/consoleFull

 I guess the question is if we need to change the test or just the regress
 output or your code. I thinkyou need to change your code (as its still not
 right, but the test output needs to be changed as well since it assumes
 screwed up behavior which we are trying to fix)

 So here is how you read it. ( If I read this right, then I've probably
 been spending way too much time talking with strk :) )

 pattern is:
 table_to_insert|srid_of_geom|type_of_geom|zmflag_geom|out_status

 for out_status:
 OK means text insert pass
 KO means text insert fail
 BOK is binary insert pass (binary is from a COPY proces so the equivalent
 of our restore)
 BKO is binary insert failure
 GOK is text geography pass, GKO: geography plain text failure etc.

 and sample of putput from debbie
 {{{
 -point|0|Point|0|KO-BKO-GKO:-BGKO
 +point|0|Point|0|OK-BKO-GOK-BGKO
 -pointm4326|0|Point|1|KO-BKO-GKO:-BGKO
 +pointm4326|0|Point|1|OK-BKO-GOK-BGKO
 }}}


 So from the above assuming I am reading these okay, I'm a little concerned
 about the fact that you can do a text rep insert but not a binary as I
 thought this was supposed to fix that issue.

 I could very well be misreading this.  But I would expect the answers to
 be for new
 not the same as the old, but not what you are emitting

 {{{
 --this is what it should be
 point|0|Point|0|OK-BOK-GOK-BGOK

 -- this is what the old returns
 point|0|Point|0|KO-BKO-GKO:-BGKO

 -- this is still wrong (assume this is with your NAN NAN)
 point|0|Point|0|OK-BKO-GOK-BGKO
 }}}


 To quickly test this is what I get with current which is wrong behavior
 (but what current emits)


 {{{
 CREATE SCHEMA tm;
 CREATE TABLE tm.point(id serial, g geometry(point), gg geography(point);

 -- note this is mimicking strk's test without resorting to backup and
 restore
  (this test is a bit flawed  as you really aren't testing POINT EMPTY but
 POINT EMTPY casted to geomety casted as text to unknown so it's dumb luck
 the answers look agreeable

 -- meh KO
 -- ERROR:  Geometry type (MultiPoint) does not match column type (Point)
 ********** Error **********
 INSERT INTO tm.point(g)
 VALUES('POINT EMPTY'::geometry::text || '');

 -- meh GKO
 INSERT INTO tm.point(gg)
 VALUES('POINT EMPTY'::geography::text || '');

 -- meh KO, BGKO
 -- ERROR:  Geometry type (MultiPoint) does not match column type (Point)
 INSERT INTO tm.point(g, gg)
 VALUES('POINT EMPTY'::geometry::bytea, 'POINT EMPTY'::geography::bytea);

 }}}

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/3031#comment:17>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.