Re: Exporting closePGconn from libpq

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