[postgis-devel] gserialized-v2

Sandro Santilli strk at kbt.io
Tue Jun 25 22:25:32 PDT 2019


On Tue, Jun 25, 2019 at 09:38:56AM -0700, Paul Ramsey wrote:
> > On Jun 25, 2019, at 2:14 AM, Sandro Santilli <strk at kbt.io> wrote:

> 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?

Yes, thank you.
I suggest we rename 0x80 to "RESERVED2" or similar, there's no need
to anticipate what it will be used for...

> Unfortunately there is only one spare, even after version change, so
> how to use it is a one-time (until v3) choice.

As long as we ensure the bit is cleared when serializing we can always
decide in a future version w/out major problems.

> 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.

I agree with "keeping" it, just not to anticipate it will be for
a version. Maybe in the future we'll consider that the "spare" bit
will be used for that, or the spare 3 bits in SRID (no plan for that?)

> 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.

I agree it is useful to keep that possibility open. Maybe put it in
a comment/suggestion that the flag will be useful for that ?

BTW: what happened to the TinyWKB serialization format idea ? Are we
missing a chance to give more attention to that now that a concept of
version is being introduced ?

--strk;


More information about the postgis-devel mailing list