Show quoted text> We have encountered multiple problems using the parser:
If I knew what you were using the module for and how you are using it
(with DBI? with SQL::Statement? with one of the existing DBDs?, with a
new DBD?), I would have a better way to understand the difficulties you
are encountering. Also, please keep in mind that SQL::Parser is a
*subset* of *SQL92* whose primary goal is to support a useful subset of
SQL for modules like DBD::CSV, DBD::Excel, DBD::DBM, DBD::AnyData and
other DBI related modules that depend on SQL::Parser, it is not intended
to be a universal parsing engine for all implementations of SQL.
Show quoted text> When you give the parser a query with an INSERT statement the parser
requires an INTO statement. This isn't logical because the SQL standards
do accept INSERTs without an INTO statement.
While "INTO" is optional in some drafts for the SQL standard, the SQL92
Standard *requires* the use of INTO in an INSERT statemtnet. I may
allow INTO to be optional in future versions of the module.
Show quoted text> It isn't possible to perform an SELECT query on multiple tables
without a JOIN or any kind of WHERE clause which acts like a link
between the tables.
That's correct, it isn't possible to do that in SQL::Statement. That's
clearly stated in the documentation. I will probably add this ability
in future versions. Patches, or co-authors are welcome :-). Seriously
- if you want to participate in the ongoing improvement of this module,
let me know, I can use all the help I can get.
Show quoted text>When you perform a query with a lot of parenthesis' the parser gives an
error like "Bad predicate: '' error: WHERE (arg=arg op arg=arg) op
(arg=arg op arg=arg) and WHERE ((arg=arg op arg=arg) op arg=arg) op
arg=arg
You're entirely right on that one. There is a bad bug in the
parentheses parsing. I am rewriting the entire parser using Parse::Yapp
which should solve this problem. I would expect to have those changes
in the module soon. My apologies for any problems this has caused.
Show quoted text> When you give the parser a query like: "SELECT * FROM test WHERE
column = 1 OR CoLuMn = 1" it loses information, the result you get only
contains the original name of the last column. (in case of making use of
multiple names which only differ on capitals)
Neither the SQL92 standard nor the DBI API requires any specific case
for the names of columns in return statements. For portability, you are
better off using NAME_lc or NAME_uc to force all column names into the
same case. Also it's logically impossible to have two different cases
for a single column in a resultset. Are you aware of any SQL
implementation that supports this?
Thanks very much for your reports.
--
Jeff
