http://www.perlmonks.org?node_id=614068


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".


Perl Contrarian & SQL fanboy

Replies are listed 'Best First'.
Re^2: Static Data, SQL::Parser
by CLovegren (Novice) on May 07, 2007 at 23:19 UTC
    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.

      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...)


      Perl Contrarian & SQL fanboy
        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. :)