Closed beajeanm closed 1 year ago
Now I think about it, Petrol has to generate a DDL valid for all the drivers, but Caqti encode timestamp using different SQL types depending on the underlying drivers... so it might be tricky 🤔
Making the types extensible is a goal that I want to explore - currently Petrol's DSL is designed around sqlite3's types and functions, but ideally, it would be nice to make the core types an extensible variant, and then allow users to import modules that extend the types for their particular SQL backends.
If you're interested in looking into it, there's an interesting type-level programming challenge in implementing this, because part of the way in which Petrol implements caching is by computing equality witnesses, but I'm not sure exactly how that would work with a user-extensible type. (I have some ideas for now, but need to try them out).
I'm afraid that might be biting more than I can chew...
No worries, I'll have a look at it sometime, but will keep you in the loop
User extensible types are now possible! See Petrol.Type.custom
. Of course, to be most useful, it would also be nice to allow users to declare additional functions, but I haven't implemented that yet.
Caqti support more types than those expose through petrol as seen at http://paurkedal.github.io/ocaml-caqti/caqti/Caqti_type/index.html. (I'm particularly interested in timestamp, but there are few others)
Are these types possible to support in Petrol? I wouldn't mind giving it a try but I wanted to check if there was a technical reason they are not present now, or it's just a list of things that didn't make the cut for a v1.