ST_Summary never reports an "S" flag (for SRID)

[strk]

We used to have an S flag out from summary as of 1.5. In 2.0 this flag disappeared. Could be due to the fact that with GSERIALIZED a SRID is mandatory, but I'd still report it as when we deserialize we deserialize into structure in which the SRID may be known or unknown…

See also #1252

[strk]

Now that #1254 is fixed (the "B" flag) its time to deal with the "S" flag. Once we figure that out we can add a regress test for st_summary.

Issue with "S" flag is wheter we want to debug the structure or the semantic. So far it's been about semantic, SRID being optional. If SRID became mandatori with GSERIALIZED, it doesn't make much sense to report its presence.

So, is it confirmed we have SRID for each and every component of collections ? Which is, did MULTIPOINT become significatively bigger in size with GSERIALIZED ?

[pramsey]

Remember to make the distinction between LWGEOM and GSERIALIZED.

For GSERIALIZED, there is one SRID, it's at the start of the structure. All sub-components are assumed to share that SRID.

For LWGEOM, every LWGEOM has an srid attribute, and during deserialization that attribute is filled in with the parent srid value and the flags are set appropriately to indicate the presence of an SRID.

[pramsey]

So, in answer to your core question, does 'S' make sense anymore, it depends. It makes no sense in terms of saying what's inside a serialization. It makes sense in terms of flagging whether a geometry has a known srid or the unknown. But if we do that, it's double book-keeping, so I'd say "no", let's not reintroduce 'S'

[strk]

Ok, agreed, let's drop the S flag from ST_Summary as a whole. Every geometry will have a SRID, and just at the top-level. All the rest is at another level (unknown vs. known) and doesn't affect storage size (while all the other flags ZMB do).