Leon Smith <leon.p.smith@gmail.com> 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
