Open tysonzero opened 1 month ago
Yes, I wouldn't really say Opaleye is "built on" postgresql-simple
as such. It's just that postgresql-simple
happened to be the simplest way to run Postgres queries when I wrote Opaleye. Indeed the part that depends on postgresql-simple
could be split off.
However, I'm not sure that gains a lot, since the I think the transitive dependencies of postgresql-simple
seem to be a subset of those of hasql
. Is there a specific problem you're hitting by having postgresql-simple
as an unused dependency?
If you want to see if postgresql-simple
could fix #325 then how about using showQuery
and just passing the query string to postgresql-simple
manually?
It looks like #325 is unrelated to hasql
anyway, just trying to seq
the Statement ()
gives me the segfault, so insert
must be the culprit, so that motivation has gone away.
Yes you bring up a fair point, in terms of true consequences, the extra dependency doesn't seem to have any real downsides (giving the ick, as the kids say, doesn't really count 😉).
To narrow this to focusing on material tradeoffs, I do stand by the other portion of my statement pointing out the upsides of having rel8
and opaleye
be more interoperable and type/pattern sharing.
I'm quite biased by my own experiences from the last 48 hours of becoming a hasql
grandmaster (i.e I can use pools and transactions) and now probably having to switch over to learning resource-pool
and postgresql-simple
for opaleye
and toss away the old code and patterns.
Opaleye itself is already built on postgresql-simple, so it seems a bit strange to me to build on top of opaleye but use hasql, leading to rel8 having both as (transitive) dependencies. It also seems to mean that using opaleye and rel8 in parallel at all, such as migrating from one to the other or using one to cover missing features in the other, is quite a bit harder. It also increases the mental overhead of switching, as you have to get used to a different connection/pooling/transaction/etc. system.
The dependency story could perhaps be resolved via
opaleye-core
/opaleye-simple
/opaleye-hasql
type package splitting, as I presume even though rel8 depends on opaleye and opaleye depends on postgresql-simple, that rel8 doesn't actually directly use any part of opaleye that uses postgresql-simple.Of course if opaleye is convinced to go down this route, a similar argument could be made for
rel8
doing the exact same thing, which may have side benefits like additional robustness in the presence of bugs inhasql
. In my case I would have liked to tryrel8-simple
to see if it would have fixed #325.