[postgis-devel] Validity flag

[Paul Ramsey]

It's a quick read at the front, rather than a full traversal to the end.
You can't know where the end is without parsing the stuff in the middle.
We can move "lesser used" flags there, so in general we won't pay the
overhead often.
If we think the flags are very particular to particular users, we
could actually typologize it, so it could be cgal_extended_info in
some cases or other_extended_info in others.
Mostly I like the optionality and the fact that it's up front so the
rest can be ignored, *or* it can condition how you deal with the rest.

P


On Sat, Mar 5, 2016 at 1:55 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Fri, Mar 04, 2016 at 10:19:22AM -0800, Paul Ramsey wrote:
>> I think the right answer is to have an "extended info" flag on the
>> main flags slot, which, if present indicates a spare 8 bytes will be
>> inserted into the header before the bounding box. This could hold less
>> commonly used flags, like the validity values (which we would have
>> room to represent as yes, no, and unknown), solidity values, and so
>> on. It will require a bit of work on the serializer/deserializer, but
>> not a lot.
>>
>> If you're OK w/ the idea, I will implement a branch of it.
>
> Could you argument a bit about why you think having 8 bytes at the
> beginning is to be preferred over having 1 byte at the end ?
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel