Changes between Version 13 and Version 14 of DevWikiPostGISCoding
- Timestamp:
- Dec 11, 2010, 4:06:30 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DevWikiPostGISCoding
v13 v14 68 68 All geometries are, at their core, collections of coordinates, just with different organizations and different interpretations between the coordinates (multi geometries versus single, or linear versus curved, or cartesian versus geodetic). The coordinates are managed inside the POINTARRAY type, in a "serialized_pointlist". When LWGEOMs are constructed from WKT or WKB (using ptarray_construct_copy_data() ), each POINTARRAY has it's own serialized_pointlist allocated and the coordinates copied into that list. When LWGEOMs are constructed from database serializations (see GSERIALIZED and PG_LWGEOM below) the serialized_pointlist is not separately allocated, it is a pointer into a position in the GSERIALIZED or PG_LWGEOM, constructed using ptarray_construct_reference_data(). 69 69 70 [[Image(screenshot_01.png)]] 71 72 [[Image(screenshot_02.png)]] 70 [[Image(screenshot_01.png)]] [[Image(screenshot_02.png)]] 73 71 74 72 Regardless of whether a POINTARRAY is database-backed, or independently allocated, the lwgeom_free() and ptarray_free() functions should automatically "do the right thing", if the POINTARRAY was built using one of the constructors provided by the POINTARRAY API. When built with ptarray_construct_reference_data(), a POINTARRAY has its FLAGS_READ_ONLY bit set, which tells the ptarray_free() function to not free the underlying serialized_pointlist (because it is not managed by the POINTARRAY, but by the database).
