FAQ

Leon Smith writes:
... The low-level binding has a couple of options:
1. Ignore the issue and allow for the possibility of a segfault if
the library is used incorrectly, which is not a good situation for
"safe" languages.
2. Create a wrapper that tracks whether or not PQfinish has ever been
called, so that attempts to use a connection afterwards can be turned
into native exceptions/other forms of error signaling. This kind of
solution can introduce their own minor issues.
3. Hack libpq to export closePGconn so that libpq can safely signal
the low-level bindings of the error when a connection is used after it
is disconnected, reserving PQfinish to run in a GC-triggered
finalizer. While this is a technically preferable solution, without
getting the change into upstream sources it is also a deployment
nightmare.
Is there any particular reason why closePGconn should not be exported
from libpq?
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.

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

regards, tom lane

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 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