Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
First attempt at a fold combinator
Untested at this point, and I know it has a few bugs and possible bugs: 1. If the correct OID/typenames aren't in the cache, getTypename will attempt to fetch the OID from the database when libpq is busy. There are a couple possible fixes: A. Fetch all oids at connection startup. B. Buffer results until the connection becomes available, then fetch oids. This breaks the resource usage of fold, though. Resource usage might be moot at this stage anyway. I believe that the database backend sends results eagerly, i.e. potentially faster than the fold can consume them. Maybe I should study Takusen. Does it create a cursor for fetching results incrementally? C. establish another connection to fetch the typename/oid pairs 2. There likely problems with exceptions, that might cause a connection to be rendered unusable.
- Loading branch information
Showing
1 changed file
with
63 additions
and
30 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bce0d38
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thought: using a database cursor to implement a fold would also have the benefit of solving the type oid conundrum, as well as it wouldn't leave libpq in the wrong state when the function passed to fold throws an exception. Also, Takusen does in fact use cursors to implement its enumerators.