[postgis-devel] lwgeom parser robustness and niceness
Carl Anderson
carl.anderson at co.fulton.ga.us
Mon Jun 7 06:03:40 PDT 2004
strk wrote:
> I've been testing lwgeom stuff.
> I've found it fault on every 'unexpected' format.
>
> All these queries kill the backend:
>
> -- EMPTY geoms
> SELECT 'POINT()'::lwgeom;
> SELECT 'MULTIPOINT()'::lwgeom;
> SELECT 'LINESTRING()'::lwgeom;
> SELECT 'MULTILINESTRING()'::lwgeom;
> SELECT 'POLYGON()'::lwgeom;
> SELECT 'MULTIPOLYGON()'::lwgeom;
> SELECT 'GEOMETRYCOLLECTION()'::lwgeom;
>
> -- NON geoms (a check for first letter is performed)
> SELECT 'P()'::lwgeom
> SELECT 'L()'::lwgeom
> SELECT 'M()'::lwgeom
> SELECT 'G()'::lwgeom
>
> -- INVALID geoms
> SELECT 'POINT(0 0 0 0 0)'::lwgeom;
> SELECT 'LINESTRING(0 0)'::lwgeom;
> SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
> SELECT 'POLYGON(0 0)'::lwgeom;
> ... try your own ...
>
> -- MIXED dimension geoms
> SELECT 'MULTIPOINT(0 0 0, 0 0)'::lwgeom;
> SELECT 'LINESTRING(0 0 0 0, 0 0 0)'::lwgeom;
> ... try your own ...
>
> Also, I don't like this error message:
>
> SELECT 'point(0 0)'::lwgeom;
> ERROR: couldnt determine if input lwgeom is WKB or WKT
>
> I think 1) it's clearly a WKT and 2) we could accept lower or mixed case
> lwgeoms, wouldn't it be acceptable in speed ?
>
> --strk;
If you edit the bison/lex files to include rules that cover the above
cases the abends stop. Not that this is the corrent fix just evidence
that it is in bison/flex
such as in wktparse.y
from
a_point: point_2d | point_3d | point_4d;
to include a rule for POINT()
a_point: empty | point_2d | point_3d | point_4d;
I am not very good with bison/flex but
I suspect that the parser code is emitting a warning that is tripping
Postgres. I have poked at the passed in error function But I think I
would need to RTFM first.
btw
moving Makefile to
$(YACC) -vd -b wktparse -p lwg_parse_yy wktparse.y
causes it to produce wktparse..tab.c and wktparse.tab.h directly
More information about the postgis-devel
mailing list