|
298 | 298 | */ |
299 | 299 | #defineFUNC_UTIL_PATCH |
300 | 300 |
|
301 | | -/* |
302 | | - * Async notifies received while a backend is in the middle of a begin/end |
303 | | - * transaction block are lost by libpq when the final end command is issued. |
304 | | - * |
305 | | - * The bug is in the routine PQexec of libpq. The routine throws away any |
306 | | - * message from the backend when a message of type 'C' is received. This |
307 | | - * type of message is sent when the result of a portal query command with |
308 | | - * no tuples is returned. Unfortunately this is the case of the end command. |
309 | | - * As all async notification are sent only when the transaction is finished, |
310 | | - * if they are received in the middle of a transaction they are lost in the |
311 | | - * libpq library. I added some tracing code to PQexec and this is the output: |
312 | | - */ |
313 | | -#definePQ_NOTIFY_PATCH |
314 | | - |
315 | 301 | /* |
316 | 302 | * Define this if you want to retrieve arrays attributes as Tcl lists instead |
317 | 303 | * of postgres C-like arrays, for example {{"a1" "a2"} {"b1" "b2"}} instead |
|