search

lpsmith / postgresql-simple

Mid-level client library for accessing PostgreSQL from Haskell
Other
206 stars 71 forks source link

[WIP] Add Cursor module #212

Closed BardurArantsson closed 7 years ago

BardurArantsson commented 7 years ago

Hi,

So this is the gist of what I want to do. It doesn't actually compile right now due to circular dependencies. (My word, how did this code get so tangled up in circular dependencies?)

Obviously it's missing documentation and I need to actually get it compiling + prettify it a little bit. Wrt. getting it compiling... is it OK if I do a little moving around of code in commits leading up to this? (If you want I can try to be extra careful to preserve the interface and just move a few implementations around and re-export to preserve the old interface. Or we could just bump versions according to PVP.)

What do you think?

EDIT: Obviously the only thing that makes sense is to view the full diff. Individual commits don't make any sense ATM.

BardurArantsson commented 7 years ago

EDIT: Scratch that.

~~Ok, so I've cleaned most of it up. All that's missing is fixing an infinite loop in doFold. The problem is pretty obvious: With the given API, there's no way of signaling a "done" condition from "fetchForward*", so I'll add that. (It may be a day or two before I get back to this. Any comments would be appreciated.)

Btw, I think everything up to the ff43f70 commit should be good to go, so feel free to merge that. I'd basically consider 8724be7 it a clean up that's worth it regardless of whatever else happens to this PR.~~

BardurArantsson commented 7 years ago

Ok, should be good to go, modulo comments... though the PR looks kind of messed up right now. Not sure what happened. I'll open a new one since you haven't commented on anything yet.

lpsmith commented 7 years ago

(My word, how did this code get so tangled up in circular dependencies?)

LOL! Honestly I'm not entirely sure. It just sorta, happened. I think the current implementation of the TypeInfo system is one of the bigger culprits, because parsing the results of query can result in further queries to the pg_type metatable, and I didn't want to have to implement these queries in terms of libpq. (Perhaps I should, just to get rid of some of the circularity)

Also, there's a less obvious circular dependency in the TypeInfo.Static module, which is generated using postgresql-simple, and is necessary for postgresql-simple to function. I think I originally created the predecessor module with a script that used Chris Done's pgsql-simple, which required almost no effort to port over to postgresql-simple. But it would be a bad idea to dynamically generate TypeInfo.Static as part of a regular build process, because well then you have some nasty circular dependencies to work with, and you need access to a running instance of postgres.