[postgis-devel] current_parser_check_flags

[Paul Ramsey]

Just to make it better: the regression tests expect validity testing
on WKT input, but not on hexwkb input. I am now aping that behavior.

postgis20=# select
astext('0103000000010000000400000000000000000024400000000000003640000000000000244000000000000040400000000000003440000000000000404000000000000034400000000000003640'::geometry);
               astext
------------------------------------
 POLYGON((10 22,10 32,20 32,20 22))
(1 row)

postgis20=# select 'POLYGON((10 22,10 32,20 32,20
22))'::geometry;ERROR:  geometry contains non-closed rings
LINE 1: select 'POLYGON((10 22,10 32,20 32,20 22))'::geometry;
               ^
HINT:  "POLYGON((10 22,10 32,20 32,20 22)" <-- parse error at position
33 within geometry
postgis20=#




On Mon, Dec 6, 2010 at 4:10 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> 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
>>>
>>
>