search

nikita-volkov / hasql

The fastest PostgreSQL libpq-based driver for Haskell
http://hackage.haskell.org/package/hasql
MIT License
518 stars 54 forks source link

Sql Syntax Check QuasiQuoter #28

Closed agrafix closed 5 months ago

agrafix commented 9 years ago

Are there any plans to introduce a rudimentary sql syntax check into the QuasiQuoter? Something like https://github.com/markdrago/pgsanity ?

nikita-volkov commented 9 years ago

I'm quite preoccupied currently, but this looks very intriguing.

The way I see it, this issue could be solved by an alternative quasi-quoter getting provided by the "hasql-postgres" library. I don't expect this to be hard to implement, if there exists a decent checker library. I haven't heard of "pgsanity" before. How do you evaluate it? We need a library with complete syntax support.

agrafix commented 9 years ago

pgsanity is just a script that calles down to ecpg. Maybe that's a bit to much to bundle in a library... I've also found https://hackage.haskell.org/package/simple-sql-parser , but I am not sure how it integrates with your parameters? I think it is not too bad if it can not parse everything, as the check should be optional.

nikita-volkov commented 9 years ago

There's actually a Postgres-specialised "hssqlppp" library by the same author. I've explored it in the beginning of the "hasql" project. It didn't seem reliably maintained enough at the time, but now it seems okay.

I'll work on this issue when I'll get some free time, which might not be very soon. If until then somebody decides to take a shot at it, please inform about it here.

I am not sure how it integrates with your parameters

This won't be a big issue, since we have an option of working around the possible incompatibility by preprocessing the string before passing it to the checker. During preprocessing we can substitute the placeholders with some dummy valid lexemes, which the checker will parse fine. The introduced extra computation will hardly be an issue, since it'll all be compile-time.

I think it is not too bad if it can not parse everything, as the check should be optional.

I agree. If we'll go with the strategy, where "hasql-postgres" provides a QQ with checking, while "hasql" provides the one without it, we'll already get this optionality.

nikolaipaul commented 5 years ago

Instead of checking the syntax, wouldn't it be possible to fire the query against the database and interpret the result?

There's something similar in the F# world:

http://fsprojects.github.io/FSharp.Data.SqlClient/

and this one does lazy schema evaluation

http://fsprojects.github.io/SQLProvider/

I'm wondering if this is doable in Haskell.

nikita-volkov commented 5 years ago

It's doable and there actually is a Haskell project doing that. Unfortunately, I don't remember the name. However I am strongly apposed to that approach, since in that way you introduce a dependency of your program's compilation on the state of the outer world, even worse, on a thing that is meant to evolve in time (the database schema). This makes compilation no longer referentially transparent, which is a ticking bomb that'll explode into unreproducible builds and maintenance nightmare.

nikita-volkov commented 5 months ago

hasql-th