From: | Leon Smith <leon(dot)p(dot)smith(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Exporting closePGconn from libpq |
Date: | 2011-05-14 15:59:12 |
Message-ID: | BANLkTikG8K1fHMnSUnM-ysBaQ0pt2fX7NQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 14, 2011 at 11:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2011-05-14 17:33:36 | Re: Reducing overhead of frequent table locks |
Previous Message | Tom Lane | 2011-05-14 15:37:41 | Re: Exporting closePGconn from libpq |