Skip Menu |
 

This queue is for tickets about the SQL-Statement CPAN distribution.

Report information
The Basics
Id: 88892
Status: rejected
Priority: 0/
Queue: SQL-Statement

People
Owner: Nobody in particular
Requestors: MJD [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.405
Fixed in: (no value)



Subject: SQL::Parser fails to parse my valid example
Download (untitled) / with headers
text/plain 674b
The attached self-contained program should return an object representing the parsed SQL. Instead it fails to parse the input, emitting the message Table 'jsr.date between brs' referenced in WHERE but not found in FROM list (alerts.board_revshare,rpt_view_job_search_net_revenue,jsr,brs)! at /tmp/sql-parse line 7 and returns undef. I don't understand why it thinks "jsr.date between brs" is a data source name. Is is possibly because it doesn't recognize the built-in function name "date_format"? But the manual does not explain how to teach the parser any more built-in function names. I'd think this would be part of the ->feature API, but if it is it's not mentioned.
Subject: sql-parse
Download sql-parse
application/octet-stream 2k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 266b
The program I uploaded was slightly the wrong version; it has an extra line that dumps out the internals of the SQL::Parser object and exits. The correct example program should omit this line, print Dumper($parser), "\n"; exit; Here is a corrected version.
Subject: sql-parse
Download sql-parse
application/octet-stream 2k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 344b
SQL::Parser emits too many warnings. When parsing the attached example, SQL::Parser's ->parse method emits *40* warning messages. I was not running the program with -w. I don't care if the module concatenates undefined values. If it is going to "use warnings", then it better be warnings-clean. This is with perl 5.12.3, if that matters.
Subject: sql-parse
Download sql-parse
application/octet-stream 2k

Message body not shown because it is not plain text.

Subject: warnings
Download warnings
application/octet-stream 5.3k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 328b
Hi MJD, you're example is valid for what? It's clearly documented that SQL::Statement has limitations parsing modern SQL dialects, so either you become more explicit here what you expect being parsed correctly or I would reject it because of "feature request SQL::Statement should behave like Oracle" or so. Best regards, Jens
Download (untitled) / with headers
text/plain 154b
On Mon Sep 23 01:52:04 2013, REHSACK wrote: Show quoted text
> Hi MJD, > > you're example is valid for what?
Sorry for this omission. It is valid for MySQL version 5.5.
Download (untitled) / with headers
text/plain 233b
But I don't understand why the ->parse method should emit forty warnings about uninitialized variables even if the input is invalid. Whatever it does, it should do without irrelevant warnings about the internal flaws of the module.
Download (untitled) / with headers
text/plain 841b
Show quoted text
> Sorry for this omission. It is valid for MySQL version 5.5.
Yes, it's know that MySQL's dialect wouldn't be understood. It's because of MySQL uses a slightly different syntax than ANSI specifies. Show quoted text
> But I don't understand why the ->parse method should emit forty > warnings about uninitialized variables even if the input is invalid. > Whatever it does, it should do without irrelevant warnings about the > internal flaws of the module.
Well, that is more or less easy to explain. It's not a good written parser - it makes to many assumptions. And they're not always correct. We're (as the team of DBI -- Tux, Riba and myself with support of Liz and maybe Tim) currently in the planning state and don't have decided yet whether only Perl6 will be supported by SQL::Statement v2 or Perl5 also. Depends on how easy we could maintain that.
MySQL (or other non-ANSI SQL Dialects) aren't intended being supported


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.