On Sat, May 14, 2011 at 11:37 AM, Tom Lane <tgl@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
