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
| [reply] |
Yes, the first step of extending the parser is to make it SQL92-safe. Unfortunatly SQL::Statement does not support all SQL92-features.
I hope I can work at it this weekend.
| [reply] |
It would be nice if SQL::Statement covered a larger subset of the "common" SQL statements and syntax. My point was that defining the larger "common" subset would be the biggest problem (IMO).
I get nitpicky when someone tells me what I'm referring to. The many SQL standards include SQL89, SQL99 and SQL-2003. I was not referring specifically to vendor extensions; more along the lines of implementations which can be incomplete or dubiously compliant. Granted, SQL92 is the standard most often heard in discussions of compliance--but, IIRC, it defines 3 different levels of compliance.
My nitpicky-ness aside, I was simply too brief in offering a dose of reality-check to the OP, who boldly claimed he was going to add support for any ".sql file" to SQL::Statement. SQL Standards and Implementations Comparison is a good starting point for anyone thinking about extending SQL::Statement to that level.
UPDATE: reordered paragraphs
--Solo
--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
| [reply]
[d/l]
[select] |
