[postgis-devel] gserialized-v2

Raúl Marín Rodríguez rmrodriguez at carto.com
Mon Jun 24 03:30:16 PDT 2019


> - lwgeom_from_gserialized() will magically work regardless of whether
> it's fed a v1 or v2 serialization, so this code all works fine when
> slapped on top of a database full of old geometries

Considering that both v1 and v2 share a lot of code and logic, I'm seeing
myself having to support both versions for a long time and I really don't like
that. Imagine porting a fix to 2.4, 2.5, 3.0-v1, 3.0-v2, 3.1-v1 and 3.1-v2. The
most likely outcome it that this change won't be backported.

That makes me wonder, do we really need to keep both versions fully functional?
Could we instead provide a function to translate from v1 to v2 and recommend
a dump + restore on upgrade? Then if we receive a v1 serialization we can
translate it and keep going or report it and recommend upgrading (similar
to what Postgres does when the catalog changes).

> - Some kind of validity caching could be put into place for larger
objects using a ValidChecked/IsValid pair of flags in the extended
area. open question for me would be -- when to set those flags, what
triggers it? obviously ST_MakeValid() could set it, but what about
automatically for any large polygons during serialization?

isValid/makeValid is extremely slow (TM). Calling them during
serialization would mean slowing most geometry altering function
by quite a bit, so even if there was a GUC to opt in/out, I don't see
myself ever using it.

> I apologize in advance for the fundamental ugliness of the work, I'm
> not an artist, I'm a tradesman.

Don't be so hard on yourself, it doesn't look all that bad :D

I've left some comments in the PR; it's easier for me to do it there.

Raúl Marín Rodríguez

More information about the postgis-devel mailing list