[postgis-devel] gserialized-v2

[Paul Ramsey]

> On Jun 25, 2019, at 2:14 AM, Sandro Santilli <strk at kbt.io> wrote:
> 
> On Sat, Jun 22, 2019 at 08:37:48AM -0700, Paul Ramsey wrote:
>> On Sat, Jun 22, 2019 at 1:05 AM Sandro Santilli <strk at kbt.io> wrote:
>>> 
>>> Where's the serialized version info, btw ?
>> 
>> In the end of the gflags. Check the contents of gserialized.h and gserialized2.h
> 
> 
> I understand this is being done a bit in rush, but I think we would
> benefit from a clear document about the new format.

Please see if the updated https://github.com/pramsey/postgis/blob/svn-trunk-gserialized2/liblwgeom/gserialized.txt <https://github.com/pramsey/postgis/blob/svn-trunk-gserialized2/liblwgeom/gserialized.txt> addresses your questions now?

> 
> I love the "G2FLAG_UNUSED", for this matter (maybe it could be renamed
> "G2FLAG_RESERVED" to clarify that we plan to use it in the future but
> current code should ensure that bit is always clear now).

Unfortunately there is only one spare, even after version change, so how to use it is a one-time (until v3) choice. LightPoint is tempting, and a feature that requires use of a bit in the primary flags slot, but I’m not sure if the 25% space savings is such a killer feature or not.

> I'm not sure I understand the use of 2 bits for the version, since we
> currently only have 2 versions (so a single bit should do).

If we take away the second version bit, this is the only version update we can do without starting to eat space just because the version is “newer”. Keeping the second bit gives us room to have two more versions without having to commit to a larger header. Given our 10-year revision cycle and the amount of room in the extended flags space, this may be a false economy, but we can always choose to steal that second version bit in the future if we so desire.

P.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190625/40f58539/attachment.html>