Re: Static Data, SQL::Parser

[renodino]

in reply to Static Data, SQL::Parser

It appears SQL::Statement has a bug, as

my $parser = SQL::Parser->new( 'ANSI', {RaiseError=>0,PrintError=>1} )
or die "No parser\n";
my $stmt = SQL::Statement->new( "SELECT 1 + 0 AS A FROM DUAL", $parser
+ )
or die "No statement";

does not produce the error. String literals also seem to be a problem.

There's an rt.cpan ticket thats kinda similar, but you might want to open a more specific one.

BTW: Keep in mind that 'ANSI' dialect ne 'Oracle' dialect; whatever storage engine you provide will have to supply its own interpretation of "DUAL".

[CLovegren]

A little more background; the project I'm working on is classifying specific chunks of data (database, table, columns, etc.) from queries used in our ColdFusion environment. I chose ANSI just because it should cover all of our different JDBC connections (Oracle 9i, DB2, SyBase, TeraData, etc.). The DUAL actually works in the query; changing 1 to a fake column name parses correctly. Since it's possible (although somewhat pointless) to include a static value in a column definition I was hoping that there might be some way to get the parser to recognize that the column name comes after the AS.

SELECT [static_value1] [AS] c1, [static_value2] [AS] c2, ... cn

The DUAL was just used as an example as we have many queries which include staticly defined values.

I guess the fastest solution will be to strip out anything which may be a static define.

[renodino]

The DUAL actually works in the query; changing 1 to a fake column name parses correctly.

Sorry, I should've been more specific. Yes, any table name will parse OK, as will omitting the FROM clause entirely. I meant to indicate that you shouldn't rely on DUAL being supported by any underlying specialization.

(Teradata ? As I live and breathe, I never expected to encounter someone on PM who actually knows what a Teradata is...)

[CLovegren]

The good thing is, I don't need them to run; I already know they do since they are in a production level environment. I may end up just grepping the data out of the queries since I don't really need the joins to work or anything of that nature; just the statement structures were exactly what I was looking for.

And as for Teradata... not my choice; seriously. We're just a reporting environment. :)