On Sat, May 14, 2011 at 11:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Yes: it'd introduce a new externally-visible state that libpq now has to > worry about supporting in all its operations, ie connection closed but > not gone. This state is guaranteed to be poorly tested and hence buggy.
If you connect to a database over an unreliable network, you can lose the connection without warning at any time. Thus libpq must already support a "connection 'closed' but not gone" state, and I'm fine with making the "explicitly disconnected" state indistinguishable from the "connection lost" state. > I think you need a wrapper object. Given the context you're describing, > I'd be willing to lay a side bet that you'll end up needing a wrapper > anyway, even if it seems like you could avoid it right now. Language > embeddings of libpq tend to accrete features... The intention of the low-level bindings I'm working on is to keep features to an absolute minimum; to bind calls to C in a 1-1 fashion and to handle memory management and error signaling associated with foreign calls. Of course such a library is not intended to be particularly attractive for application development, but rather as a library that can be wrapped up into a higher-level database access library that's free to accrete features. :) Best, Leon -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
