FAQ

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.
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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 5 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 14, '11 at 3:23p
activeMay 16, '11 at 12:17p
posts5
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase