[postgis-devel] current_parser_check_flags

[Paul Ramsey]

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
>