Exporting closePGconn from libpq
От | Leon Smith |
---|---|
Тема | Exporting closePGconn from libpq |
Дата | |
Msg-id | BANLkTi=qkJg0EvYcn1jYUhP5F1pwhYUWRw@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Exporting closePGconn from libpq
Re: Exporting closePGconn from libpq Re: Exporting closePGconn from libpq |
Список | pgsql-hackers |
A minor issue has come up in creating low-level bindings to libpq for safe garbage-collected languages, namely that PQfinish is the only (AFAICT) way to close a connection but also de-allocates the memory used to represent the database connection. It would be preferable to call PQfinish to free the memory in a finalizer, but appilcations need a way to disconnect from the database at a predictable and deterministic point in time, whereas leaving a bit of memory around until the GC finally gets to it is relatively harmless. 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? Best, Leon
В списке pgsql-hackers по дате отправления: