[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):
David,
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