in reply to problems using SQL::Statement

You can explicitly allow BLOBs by doing
$parser->feature('valid_data_types','BLOB',1);
before parsing the statement.

If you look at SQL::Statement::Syntax, you can see that specifying the primary key (or any other constraint) at the end of the column list is not supported. You might be able to extend the parser, but I don't know how difficult that would be.

In stead, you can (in this instance) specify the primary key constraint as a column constraint. This is what works for me:

use strict; use SQL::Statement; my $statement = qq~CREATE TABLE test( ID int not null primary key, Spalte1 varchar(255), Spalte2 int, Spalte3 int, Spalte4 int, Spalte5 blob, Spalte6 varchar(33), )~; my $parser = SQL::Parser->new(); $parser->feature('valid_data_types','BLOB',1); my $stmt = SQL::Statement->new($statement,$parser);

Replies are listed 'Best First'.
Re^2: problems using SQL::Statement
by reneeb (Chaplain) on Jul 29, 2005 at 14:35 UTC
    Thanks for your answer, I will try to extend the parser.

    Your provided solution would not solve the whole problem. Any .sql-file that adhere to the SQL-standard should be accepted.
      Any .sql-file that adhere to the SQL-standard should be accepted.

      Exactly which standard(s) would be one of the bigger problems when extending the parser.

      --Solo

      --
      You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

        It should adhere to the SQL92 standard at a minimum. What you're referring to is the SQL extensions (Transact SQL Sybase & Microsoft, PL/SQL Oracle & Postgres, etc.). The extensions make multi-vendor dbms support a pain.

        Jason L. Froebe

        Team Sybase member

        No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1