[GRASS-dev] [grass-code I][520] v.overlay: "SQL parser error" if output name is "and", "or" or "not"

grass-dev@grass.itc.it wrote:

code I item #520, was opened at 2007-10-23 19:33
Status: Open
Priority: 3
Submitted By: Maciej Sieczka (msieczka)
Assigned to: Nobody (None)
Summary: v.overlay: "SQL parser error" if output name is "and", "or" or "not"
Issue type: module bug
Issue status: None
GRASS version: CVS HEAD
GRASS component: vector
Operating system: all
Operating system version:
GRASS CVS checkout date, if applies (YYMMDD): 071023

Initial Comment:
I don't think vector names same as logical operators are not allowed. But they make v.overlay fail:

$ v.overlay ainput=small_box atype=area binput=big_box btype=area output=not operator=and

Copying vector objects from vector map <small_box>...
100%
Collecting input attributes...
WARNING: Database connection not defined for layer 1
Copying vector objects from vector map <big_box>...
100%
Collecting input attributes...
WARNING: Database connection not defined for layer 1
DBMI-DBF driver error:
SQL parser error:
in statement:
create table not (cat integer , a_cat integer, b_cat integer )
Error in db_execute_immediate()

ERROR: Unable to create table: 'create table not (cat integer , a_cat
       integer, b_cat integer )'

Same v.overaly command line, but with output other than "and", "or", "not", works OK.

Vector attributes are stored in a table whose name is exactly the same
as the vector map, so a GRASS vector name must be valid as an SQL
table name.

This isn't something which can easily be fixed without breaking
existing setups. I'm not even sure that it's possible to detect in
advance whether a given name is valid.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

$ v.overlay ainput=small_box atype=area binput=big_box btype=area output=not operator=and

Copying vector objects from vector map <small_box>...
100%
Collecting input attributes...
WARNING: Database connection not defined for layer 1
Copying vector objects from vector map <big_box>...
100%
Collecting input attributes...
WARNING: Database connection not defined for layer 1
DBMI-DBF driver error:
SQL parser error:
in statement:
create table not (cat integer , a_cat integer, b_cat integer )
Error in db_execute_immediate()

ERROR: Unable to create table: 'create table not (cat integer , a_cat
       integer, b_cat integer )'

Same v.overaly command line, but with output other than "and", "or", "not", works OK.

Vector attributes are stored in a table whose name is exactly the same
as the vector map, so a GRASS vector name must be valid as an SQL
table name.

I see. This is indeed not a a problem with overlay. Eg. g.copy:

$ g.copy vect=map,and
Copy vector <map@set1> to current mapset as <and>
DBMI-DBF driver error:
SQL parser error:
in statement:
create table and ( cat integer )
Cannot create table

WARNING: Cannot create new table
WARNING: Unable to copy table <and>
WARNING: Cannot copy <map@set1> to current mapset as <and>

This isn't something which can easily be fixed without breaking
existing setups. I'm not even sure that it's possible to detect in
advance whether a given name is valid.

Some not SQL compliant names are already rejected. g.copy again:

$ g.copy vect=map,1
Copy vector <map@set1> to current mapset as <1>
WARNING: Illegal vector map name <1>. Must start with a letter.
ERROR: Vector map name is not SQL compliant

Maybe there is a way to extend the test to reject names and,
or, not? Should xor be rejected too? For now vectors and
tables named "xor" are allowed and don't trigger SQL parser
error like and/or/not?

Maciek

Maciej Sieczka wrote:

> This isn't something which can easily be fixed without breaking
> existing setups. I'm not even sure that it's possible to detect in
> advance whether a given name is valid.

Some not SQL compliant names are already rejected. g.copy again:

$ g.copy vect=map,1
Copy vector <map@set1> to current mapset as <1>
WARNING: Illegal vector map name <1>. Must start with a letter.
ERROR: Vector map name is not SQL compliant

Maybe there is a way to extend the test to reject names and,
or, not? Should xor be rejected too? For now vectors and
tables named "xor" are allowed and don't trigger SQL parser
error like and/or/not?

"xor" isn't an SQL keyword.

There is a list of SQL keywords at:

http://www.postgresql.org/docs/8.2/static/sql-keywords-appendix.html

That list has 632 entries; some of them are only reserved in specific
contexts, or in specific versions of the SQL standard. Beyond that,
specific SQL implementations may have their own idea of what is or is
not permissible.

--
Glynn Clements <glynn@gclements.plus.com>