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