Bug #88892 for SQL-Statement: SQL::Parser fails to parse my valid example

Sun Sep 22 19:53:37 2013 MJD [...] cpan.org - Ticket created

Subject:

SQL::Parser fails to parse my valid example

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.

Sun Sep 22 19:56:54 2013 MJD [...] cpan.org - Correspondence added

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.

Sun Sep 22 20:00:24 2013 MJD [...] cpan.org - Ticket #88893: Ticket created

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.

Mon Sep 23 01:52:04 2013 REHSACK [...] cpan.org - Correspondence added

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

Mon Sep 23 01:52:04 2013 The RT System itself - Status changed from 'new' to 'open'

Mon Sep 23 01:52:54 2013 REHSACK [...] cpan.org - Ticket #88893: Merged into ticket #88892

Mon Sep 23 01:52:54 2013 REHSACK [...] cpan.org - Merged into ticket #88892

Mon Sep 23 03:56:08 2013 MJD [...] cpan.org - Correspondence added

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.

Mon Sep 23 04:04:56 2013 MJD [...] cpan.org - Correspondence added

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.

Mon Sep 23 05:59:59 2013 REHSACK [...] cpan.org - Correspondence added

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.

Tue May 26 03:42:17 2015 REHSACK [...] cpan.org - Correspondence added

MySQL (or other non-ANSI SQL Dialects) aren't intended being supported

Tue May 26 03:42:25 2015 REHSACK [...] cpan.org - Status changed from 'open' to 'rejected'