INV_WRITE is a small lie; as it is has the same effect as INV_READ | INV_WRITE. Actually, I don't think the change to loWrite changes much, as the lseek shouldn't fail unless the database connection is lost or the fd returned an error, in which case we handled the error anyway. Maybe there is a failure mode of lo_lseek I don't understand. It seems the real difference is that we avoid a C call in the error path.
TODO: 1. figure out which foreign imports should be marked safe 2. move connection out of MVar so that the lock need not be taken. (It's probable that several of the functions need not take the lock, e.g. loRead. But I need to verify this with somebody more knowledgable about Postgres and libpq than I.) 3. Fix error handling on multiple counts A. check if returned Oids are zero B. handle all error codes appropriately
…ribePrepared, and describePortal. Revised documentation and code ordering.
…aramtype, and added Column and Row newtypes to help avoid silly mistakes.
…n, serverVersion, connectionNeedsPassword, and connectionUsedPassword.
…se MVar and Maybe to deal with closed connections.
…tWrite before resetPoll in reset.
…alling connectPoll for the first time.
I got rid of failErrorMessage in favor of returning booleans or Maybe x return types. I also fixed the symantics of the exec calls to return the LAST available result.