Building on opaleye but also depending on hasql seems surprising

[tysonzero]

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 in hasql. In my case I would have liked to try rel8-simple to see if it would have fixed #325.

[tomjaguarpaw]

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?

[tysonzero]

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.

[avanov]

and now probably having to switch over to learning resource-pool and postgresql-simple for opaleye and toss away the old code and patterns.

@tysonzero not sure if it's still relevant, but I've got https://hackage.haskell.org/package/hasql-resource-pool if you need both the resource-pool and hasql, it derives from a time when hasql-pool had a resource-pool as a dependency implementing the pool, and I've got software that I can't migrate to the new hasql-pool yet.

[xave]

Just to add another perspective:

Opaleye covers a lot of common SQL cases. For those special situations where one, for instance, wants to perform a "SELECT-valued INSERT or UPDATE", it makes sense to drop down into something like postgres-simple or hasql. At present, I'm leaning towards liking opaleye and hasql conceptually. That would lead me to want both of those as deps for the escape hatch situation.

---

Note: I haven't tried to do any unsupported things; I am just thinking ahead for the case where I inevitably do. Basing the above example off of the comment in the TutorialManipulation.hs docs.

Comments
========

Opaleye does not currently support SELECT-valued INSERT or UPDATE.