use Perl

• DBI::DBD (Score:3, Informative)

  by Theory (10) on 2003.03.24 10:26 (#18247) Homepage Journal

  The canonical documentation for DBD writers is DBI::DBD [cpan.org].

  --David

  Reply to This
• My experiences writing DBD::google (Score:2, Informative)

  by dlc (50)

  When I started writing DBD::google, there was only one thing to go by: DBI::DBD, which gives a basic but servicable intro to writing a DBD. Since then, Takanori Kawai released DBD::Template, which provides a pretty good starting point, mostly (it seems) encapsulating the good advice from DBI::DBD.

  As far as SQL::Statement goes, I initially wrote DBD::google without it, but am rewriting it to subclass SQL::Parser and implement it's own feature set, which (SELECT-wise) is a superset of ANSI SQL, but in all

  --
  (darren)
• secret project (Score:1)

  by Robrt (1414)

  For a secret project I worked on (which will eventually may DBD::Something) it was easier to write a new regex based SQL-like parser. SQL::Statement (a few months ago) was too strict, and didn't allow me to bend the rules.
  • Re:secret project (Score:2)

    by jdavidb (1361)

    Has anyone considered a Parse::RecDescent based SQL parser?

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • Re:secret project (Score:1)

      by dlc (50)

      Has anyone considered a Parse::RecDescent based SQL parser?

      Take a look at SQL::Translator (on CPAN [cpan.org], also at http://sf.net/projects/sqlfairy/ [sf.net]), which is a set of modules designed to translate the CREATE syntax of one DB into another. Many of the parsers we currently have (MySQL, Sybase, Pg, Oracle) are based on Parse::RecDescent.

      --
      (darren)
    • Re:secret project (Score:1)

      by babbage (2619)

      It's not exactly what you mean, but Damian uses Parse::RecDescent to go the other way, turning English questions into valid SQL statements. If it's possible to go that way, surely parsing the much-more-regular-than-English SQL variant of any particular database has to be feasible.

      Random thought: would it make any sense to skip ahead a bit by poking around in the source of open source databases like MySQL & PostgreSQL and using their SQL parsing code as the basis for a general purpose SQL interpreter?

      --
      

      
      --
      DO NOT LEAVE IT IS NOT REAL.
      • Re:secret project (Score:1)

        by dlc (50)

        Random thought: would it make any sense to skip ahead a bit by poking around in the source of open source databases like MySQL & PostgreSQL and using their SQL parsing code as the basis for a general purpose SQL interpreter?

        The SQL::Translator [cpan.org] folks have discussed (OK, I brought it up [sourceforge.net]) using the provided yacc grammars as the basis for the MySQL and Pg parsers, although none of us has done anything with it yet.

        Patches welcome... [sf.net]

        --
        (darren)
        • Re:secret project (Score:1)

          by babbage (2619)

          <diamond> "Patches welcome" is the lowest form of sarcasm. </diamond>

          --
          

          
          --
          DO NOT LEAVE IT IS NOT REAL.
  • Re:secret project (Score:1)

    by dlc (50)

    SQL::Statement (a few months ago) was too strict, and didn't allow me to bend the rules.

    I had a conversation about this very topic with Jeff Zucker a few weeks ago, because I had the same issues with SQL::Statement. He pointed me at SQL::Parser, upon which SQL::Statement is based, and which is much more flexible. You simply need to subclass SQL::Parser, and override the methods that aren't flexible enough for you.

    Also, the guts of SQL::Parser are regex-based, and Jeff seems pretty open to accepting id

    --
    (darren)