[postgis-devel] gserialized-v2

[Paul Ramsey]

> On Jun 24, 2019, at 3:30 AM, Raúl Marín Rodríguez <rmrodriguez at carto.com> wrote:
> 
> Hi,
> 
>> - 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.

It’s possible to merge to code lines, since they are quite similar. But I deliberately did not do that so that I could effectively quarantine the old, reliable, code. I don’t foresee a lot fo maintenance effort on the v1 code, because it’s been static and untouched for so long. The main benefit of merging the lines is avoid the big version switch in gserialized.c

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

I really don’t want to force people through a dump/restore. We reserved flags in the old serialization specifically so we could avoid it. It was a huge pain in the 1.x/2.x transition and people rightfully hated it. We can do better, and people expect to have dump-less upgrade.

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

Yeah, the whole “cache valid state” thing founders on the question of when precisely to do the checking. If you don’t pay the validity check cost at least once, you can’t reap the benefit of having the state cached later on. As I thought about implementing it I got progressively less motivated, the usefulness of it sort of dissolved in my head.

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

Thanks,

P

> 
> Regards,
> --
> Raúl Marín Rodríguez
> carto.com
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel