Typed sql

[vcombey]

Limit: from what i understood, the strategy using prepare statement in sql is not enough to infer the nullability of LEFT JOIN / RIGHT JOIN. so any queries with those would put all fields in maybe..
We will see when I add tests.

[mpscholten]

Fixes #1284

[vcombey]

should i rebase it to switch-to-hasql branch ? is the migration to hasql finished. I honestly doesn't understand anything about hasql. Postgres-simple was so much simpler.
Are users suposed to migrate from postgres-simple to hasql ?
Is it to have better type check ? or for the performance ?
then could this typedsql quasiquoter become the user facing default for doing sql queries along with ihp "orm" ?
@mpscholten

[mpscholten]

likely we'll not merge the switch-to-hasql branch branch. rebasing with master should already bring in all the hasql stuff. Current ihp master has a hybrid postgresql-simple and hasql way for now. Dropping pg simple would break too much, so we just use hasql wherever possible and stick to pg simple for the rest.

hasql is much faster (2 - 3x) because it uses prepared statements and the binary protocol of Postgres (pg simple is textual). I think it's in fact faster than the normal postgres c bindings.

its most complex but the majority of code will be written by ai agents in the future anyways, so we can accept this additional complexity.

the user facing parts of the ihp arm (createRecord, updateRecord, deleteRecord, query |> fetch) will not change, so for most users nothing changes except that it's 2x faster.

then could this typedsql quasiquoter become the user facing default for doing sql queries along with ihp "orm" ?

yes 👍 I think together with the other crud functions. especially since it hides all the complexity of hasql. also llms are very good at raw sql, so this should be a good addition for the agentic future.