Summary: A parser, pretty printer, and type checker for PostGreSQL SQL and PL/pgSQL. BSD licensed. The current aims of the project is to provide a parser and type checker for a substantial portion of PostGreSQL SQL and PL/pgSQL. Status: it successfully parses and accurately pretty prints the three moderate sized SQL files from another project of mine, but there are lots of missing bits. Coverage of SQL is reasonable, see below for more details on what is supported and unsupported. It also has the beginnings of a type checker, which currently can type check a large subset of expressions and selects that the parser can parse, but is in an early state. You can run the type checker on your SQL, see the 'usage' file for details. There is a command line wrapper, HsSqlSystem.lhs, which provides some utility functions to access some of the library code. It comes with a small test suite. There is not much documentation at the moment. See the 'usage' file where there are instructions on how to parse files, and type check them to see how well the code supports your SQL source. Most of the source files have plenty of comments, hopefully they can provide some illumination. It comes with a Cabal file, so you can compile it by unzipping and using cabal configure && cabal build in the usual way. I think it should work on all GHC 6.10.x and possibly also GHC 6.8.x. See the file 'development' for some notes on how to work with the source. The main dependencies of this project are: Parsec 3, HUnit, HDBC and UUAGC. ================================================================================ Homepage The project is hosted on Launchpad http://launchpad.net/hssqlppp/ You can get the latest code using Bazaar: bzr branch lp:~jakewheat/hssqlppp/trunk Contact Let me know if you're using/ interesting in using the library, if you have any problems or suggestions, etc.. All contributions, comments and criticism welcome: jakewheatmail@gmail.com You can also report problems on the bug tracker on Launchpad. Let me know if you have any problems trying out the stuff in the 'usage' file, if you come across some SQL which doesn't parse or type check, and I'm also interested in surveying what other dialects of SQL you would be interested in using or contributing code for, and if you want to fork the project (which is something I have nothing against). ================================================================================ = Syntax supported/ not supported: == Parsing Partially supports: select statements (selectlists (*, qualified, aliased/correlation names, expressions) distinct, basic window functions, from (with explicit joins - natural, inner, cross, left, right, full outer, on and using), aliases, from functions where, group by, having, order by, limit, offset except, intersect, union expressions: subselects, in, row ctors, strings + dollar strings, integers, case, exists, boolean literals, null, arrays and subscripting (slightly limited), function calls, identifiers, cast(x as y), between (quite limited), substring(x from a for b) also partially supports: insert (with multiple values and select support), update, delete (all three with returning) create and drop table, type, view, domain create function for sql and plpgsql functions all constraint types sort of skips copy statements instead of erroring plpgsql statements: select into null continue perform execute assignment if return, return next, return query raise for (select and integer variants) while case statement Many things are missing at the moment, in particular selects: cte, implicit joins joins in updates (delete from, update using) alter statements create and drop apart from table, view, domain, type, function transaction commands triggers and trigger functions loop statement, labels error trapping cursors This is a non-exhaustive list. Expression support is patchy, should work pretty well for a lot of simple stuff though. There is a strong possibility that for some complex selects and expressions, the implicit precedence (that is, bits without enclosing parenthesis) may parse in the wrong direction. Please let me know if you encounter such an error. == Type checking Type checking supports a good subset of expressions and select statements that the parser parses, and has basic support for insert, update, delete and the various create statements that the parser supports. Development work is currently focused in this area. = Other current downsides: The AST node types aren't well designed, in particular they contain almost no location information, and no other annotations. This is due to be fixed and is near the top of the TODO list. Not much work has been done on correctly rejecting invalid SQL and not much thought has been put into error messages and error reporting yet, this is slowly improving, and at some point will become a major focus. Supporting other SQL dialects: I think it might be realistic to support portable select, insert, update and delete with ? placeholders. I think cross platform DDL isn't ever going to be sensible in non toy databases, and if you wanted to use this utility e.g. support MySQL or MS SQL Server, start by forking the code. Future plans: * use this system to develop a Lint-type checker for PL/pgSQL; * support type checking simple SQL statements that you'd embed in Haskell code, including with ? placeholders, to support generating type safe wrappers; * possibly a lightweight code generation/ simple macro support to help with developing more robust PL/pgSQL code.