[mapserver-dev] mappostgis.c

[Steve Lime]

A good threat, probably long overdue. Do you have any feel for the performance end of things? I
recall the Geoserver tests showing GeoServer performing substantially better than MapServer w/regards
to PostGIS. 

Steve

>>> On 11/4/2008 at 11:27 AM, in message
<30fe546d0811040927n51812e1do272f2cb1bac836b4 at mail.gmail.com>, "Paul Ramsey"
<pramsey at cleverelephant.ca> wrote:
> FYI, as threatened, I have updated the postgis driver in trunk rather
> substantially.  The binary cursor is gone, the SQL generation is a bit
> more modular, much of the code duplication is removed, some memory
> leaks are removed, I'm sure some others have been added (valgrinding
> is still on the to-do list). In general the complexity is a lot lower
> without the binary cursor, so it's all worthwhile.
> 
> I put some prototypes and structs in mappostgis.h, so I could bring
> them into my unit tester more easily. The other thing on my "unit
> testers wishlist" would be having the mapserver Makefile put things
> like the INCLUDE paths and LIB flags and -D lists in a place where
> other Makefiles could import them. For external apps making use of
> libmapserver.a, it would be quite handy.
> 
> mappostgis.c has received light testing in map, query, nquery,
> itemquery and itemnquery modes and seems to hold up OK. (Watching the
> debug log during the nquery mode is especially horrifying, I had
> forgotten the full extent of the inefficiency of the current set-up.)
> 
> If you happen to have PostGIS applications around, I would be
> interested to hear if things still work "as expected" in trunk.
> 
> I did add in support for maxfeatures as well, but will probably have
> to alter it a bit if we do an RFC on paging, since both query and map
> mode are respecting maxfeatures as it stands.
> 
> P.
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev