Re^4: problems using SQL::Statement

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

Comment on Re^4: problems using SQL::Statement

Replies are listed 'Best First'.
Re^5: problems using SQL::Statement by reneeb (Chaplain) on Jul 29, 2005 at 16:28 UTC
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]
Re^5: problems using SQL::Statement by Solo (Deacon) on Jul 29, 2005 at 21:11 UTC
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]