Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sql Syntax Check QuasiQuoter #28

Closed
agrafix opened this issue Mar 11, 2015 · 6 comments
Closed

Sql Syntax Check QuasiQuoter #28

agrafix opened this issue Mar 11, 2015 · 6 comments

Comments

@agrafix
Copy link
Contributor

agrafix commented Mar 11, 2015

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

@nikita-volkov
Copy link
Owner

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
Copy link
Contributor Author

agrafix commented Mar 12, 2015

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
Copy link
Owner

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
Copy link

nikolaipaul commented Mar 15, 2019

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
Copy link
Owner

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
Copy link
Owner

hasql-th

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants