[postgis-devel] [PostGIS] #926: ST_GeometryN, ST_PointN (input of array) return set

PostGIS trac at osgeo.org
Thu Apr 28 21:01:11 PDT 2011

#926: ST_GeometryN, ST_PointN (input of array) return set
 Reporter:  robe         |       Owner:  pramsey      
     Type:  enhancement  |      Status:  new          
 Priority:  medium       |   Milestone:  PostGIS 2.0.0
Component:  postgis      |     Version:  trunk        
 Keywords:               |  

Comment(by robe):

 Don't take offense.  Perhaps that was not the right word to use.
 Kludgy and heinous is nicer than cryptic :)  Actually I thought a lot of
 things look cryptic if you haven't seen them before.  accessing composite
 objects looks cryptic, the first time you see it, the way Oracle spatial
 folks access their geometries with arrays looks cryptic, but many will
 defend it to the ground why its better and more efficient than what
 everyone else does and they are probably right.

 With that said even the array thing above now that I think about it would
 look a bit cryptic, but its shorter.  Yah shorter is what I was going for.

 You see any issues with this approach?

 What my idea is keep ST_DumpPoints as an SQL implementation and just do
 these in C.  I can almost imagine doing these myself in C so I think
 probalby easier than implementing ST_DumpPoints in C.

 I think current dump point weak point is the dumping of linestring points
 as your approach clearly demonstrated, but if we can have these helper
 functions in C, it will open the door for a lot more fast terse SQL /
 PLPGSQL function implementations was my thinking.

 You think returning points / geometries as a SET is better than an  array
 or would an array make more sense and people can unnest if they want.  I'm
 not sure if there is a performance or usability benefit to outputting it
 as an array from postgis layer instead of a set.

Ticket URL: <http://trac.osgeo.org/postgis/ticket/926#comment:2>
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.

More information about the postgis-devel mailing list