pramsey at opengeo.org
Tue Dec 7 09:44:09 PST 2010
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.
POLYGON((10 22,10 32,20 32,20 22))
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
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.)
> 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
>> 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);
>> POLYGON((10 22,10 32,20 32,20 22))
>> (1 row)
>> So, decision point: input validity checks or not?
>> 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.)
>>> 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:
>>> This merge is just plain wrong in that it ignores all of the passed flags
>>> and appears to enforce all checks regardless :(
>>> Mark Cave-Ayland - Senior Technical Architect
>>> PostgreSQL - PostGIS
>>> Sirius Corporation plc - control through freedom
>>> t: +44 870 608 0063
>>> Sirius Labs: http://www.siriusit.co.uk/labs
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
More information about the postgis-devel