Request for documentation and design-decisions

[saurabhnanda]

This seems like a really interesting library, especially the type-checking part. Would it be possible to answer the following questions:

• What was the original intended purpose for this library?
• Has the PG SQL parser been implemented from scratch in Haskell? Why not bind to the existing PG bindings?
• Why does it say that it's still in pre-alpha stage? What is not working currently?
• Is the project being actively maintained? What is its future vision?

[abhin4v]

@saurabhnanda It works wonderfully. It's a bit lacking in documentation but I used http://jakewheat.github.io/hssqlppp/latest/ and a bit of reading through the source code itself to use it in my project https://github.com/abhin4v/ringo/ to generate SQL.

[JakeWheat]

What was the original intended purpose for this library?

I had some code which was a prototype for an application development
system, and it used mainly plpgsql, with a lot of code generation done
within plpgsql using string concatenation, and the maintainability was
getting worse and worse. I originally wrote hssqlppp to help with
this.

Has the PG SQL parser been implemented from scratch in Haskell?

Yes.

Why not bind to the existing PG bindings?

I had no idea these existed until now. But I think the level of
detail captured, and the coverage of different SQL statements is not
nearly enough for what I want.

Why does it say that it's still in pre-alpha stage? What is not working currently?

I mean pre-alpha with respect to the stability of the interface.This
is still in flux and changes a lot between major releases. There are
also some smallish gaps in the parser, and quite a lot of gaps in the
type checker (including some big regressions wrt typechecking with ddl
statements).

If you are just parsing and type checking queries and dml then I don't
think you will come across any issues or these gaps.

Is the project being actively maintained? What is its future vision?

It is being actively maintained, but only very slowly and with some
latency. It is in more development internally in Sqream, and all the
changes to the hssqlppp code are released on github.

The future vision at the moment is to

• improve the implementation of dialect handling
• support more of ansi sql, port the parsing code from
  a newer project which does parsing only (simple-sql-parser) - it is
  much better written
• I am also looking at replacing parsec with megaparsec or maybe
  uu-parsinglib or possibly something else (but still a haskell parser
  combinator)
• improve the typechecking, especially some of the implementation is a
  mess
• improve the error messages
• improve the quality of the code and the code documentation

There is a more detailed todo full of things which I never get round
to:
https://github.com/JakeWheat/hssqlppp/blob/master/todo

[JakeWheat]

abhin4v, can you give some more details on what is lacking in the documentation, maybe I can work on some of this

[saurabhnanda]

I had no idea these existed until now. But I think the level of detail captured, and the coverage of different SQL statements is not nearly enough for what I want.

In what way? Wouldn't PG's internal query parser always be up-to-date and comprehensive?

[JakeWheat]

Yes, I think you are right that it is comprehensive for select statements. But when I originally wrote hssqlppp, I already was trying to parse, insert/update/delete, ddl and create function statement bodies also.

Maybe if I had seen this at the time I would have tried to use it (and extend the c code to cover the extra kinds of statements), but I wouldn't like to be maintaining a fork of some postgres code in c, or to require postgres in order to use hssqlppp. In addition, extending the parser in c to support new syntax or other SQL dialects isn't something that I would like to try and do, if it is even feasible.