[postgis-devel] current_parser_check_flags

[Paul Ramsey]

Sorry to be crystal clear:

- In 2.0 (and in 1.5) the lwgeom_in functions are called with
PARSER_CHECK_ALL however,
- In 2.0 (and in 1.5) the checks are not actually run.
- In 2.0 there is now a clean.sql regression tests that loads in
polygons with unclosed rings (and then presumably cleans them).
Because my new WBK reader both declares PARSER_CHECK_ALL and actually
checks, I cannot pass this regression.

(This is the last regression I have to pass / alter before I can commit back.)

Paul

On Mon, Dec 6, 2010 at 4:08 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> Sorry, revisiting this...
>
> Grep through 1.5 svn for 'current_parser_check_flags' and see what's
> going on. It looks like there are no input checks in 1.5 right now
> either.
>
> This is coming because when I am failing the clean.sql regression
> test, which includes a table load that has some unclosed rings. My new
> WKB reader, like the old one, is called with PARSER_CHECK_ALL, but
> unlike the old one it *actually checks things*. It looks like the
> reader in both 1.5 and 2.0 has had input validity checks disabled, and
> we're actually not counting on that in regression.
>
> For example, try this:
>
> select astext('0103000000010000000400000000000000000024400000000000003640000000000000244000000000000040400000000000003440000000000000404000000000000034400000000000003640'::geometry);
>               astext
> ------------------------------------
>  POLYGON((10 22,10 32,20 32,20 22))
> (1 row)
>
>
>
> So, decision point: input validity checks or not?
>
> Paul
>
>
> On Thu, Oct 21, 2010 at 4:49 AM, Mark Cave-Ayland
> <mark.cave-ayland at siriusit.co.uk> wrote:
>> Paul Ramsey wrote:
>>
>>> I'm slowly working through getting a new WKT-to-LWGEOM parser in
>>> place, and the first steps are the longest, as I have to replicate the
>>> behaviour and API of the current parser... so having got to the point
>>> of extracting location information and handling error conditions I'm
>>> now looking at the parser check flags. And strangely, though I can see
>>> quite clearly where the current_parser_check_flags global is set at
>>> the start of the parse phase, I cannot see anywhere thereafter that
>>> refers to the value of that global. I would, looking at the code, say
>>> the checks are being ignored, if not for the fact that I can run SQL
>>> and actually see them being applied... so: how does this work? Mark?
>>> (Strictly speaking, I don't need to know how the current stuff works
>>> in order to make my stuff enforce the checks, but I don't like being
>>> ignorant in this way.)
>>>
>>> P.
>>
>> What the heck? The checks have been totally removed?!
>>
>> ...goes and looks back over the SVN history...
>>
>> OMG. It looks like the entire set of checks got hosed when Mark re-merged
>> his parser changes back into trunk (and 1.5) here:
>>
>> http://trac.osgeo.org/postgis/changeset/3821/trunk/liblwgeom/lwgparse.c
>>
>> This merge is just plain wrong in that it ignores all of the passed flags
>> and appears to enforce all checks regardless :(
>>
>>
>> ATB,
>>
>> Mark.
>>
>> --
>> Mark Cave-Ayland - Senior Technical Architect
>> PostgreSQL - PostGIS
>> Sirius Corporation plc - control through freedom
>> http://www.siriusit.co.uk
>> t: +44 870 608 0063
>>
>> Sirius Labs: http://www.siriusit.co.uk/labs
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>