search

morphismtech / squeal

Squeal, a deep embedding of SQL in Haskell
362 stars 32 forks source link

[quick question] MS SQL Server instead of Postgresql #278

Closed giuliohome closed 3 years ago

giuliohome commented 3 years ago

Quick, stupid question: how would be difficult to write a port to another dbms? More techincally, what is specific to the support dbms here? I guess it is a lot of work, because I see that all the (select, join, sql and so on ...) logic is under that kind of db. So where is the abstraction power of haskell? Sorry, I don't intend to be rude, but just to honestly understand. Clear, you may be interested only in a type-safe interaction with that specific dbms, but it defeats the point of abstraction, doesn't it? You use monads, monoids and friends because you want to generilse as much as possible, right?

echatav commented 3 years ago

I think it would be some work but straightforward to port Squeal to MS SQL. Some libraries do abstract out the particular choice of database backend but I chose not to. The main reason is that you end up only able to truly support an intersection of features (and types) supported across your backends. Also, it would certainly add to the complexity of the library while being of dubious utility (being able to switch your backend at some point). I think that a port of Squeal makes more sense and would be simpler, which is why I named the library squeal-postgresql so it could be supplemented by squeal-mssql and whatnot if someone wanted to build it.

Clear, you may be interested only in a type-safe interaction with that specific dbms, but it defeats the point of abstraction, doesn't it? You use monads, monoids and friends because you want to generilse as much as possible, right?

Abstraction should clarify, as mathematical abstractions do. But abstraction for the sake of abstraction is not a design principle for Squeal.

giuliohome commented 3 years ago

Thank you for your clarification.