Changes between Version 10 and Version 11 of DevWikiPostGISCoding

Timestamp:

Dec 11, 2010, 3:52:49 PM (13 years ago)

Author:

pramsey

Comment:

—

DevWikiPostGISCoding

@@ -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().
 
-Regardless of whether a POINTARRAY is database-backed, or independently allocated, the memory management should automatically "do the right thing", if the POINTARRAY was constructed using one of the constructors provided by the POINTARRAY API. When constructed 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).
+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).