Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes |
Дата | |
Msg-id | 8596.893860094@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes (ocie@paracel.com) |
Ответы |
Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
|
Список | pgsql-hackers |
ocie@paracel.com writes: > You didn't come right out and say it, but are you intending to support > multiple queries within a connection? I gather not. Not that I'm > suggesting that this be done, as it seems this would complicate the > user's application and the backend. With only one possible OOB > message, you can't tell it which query to cancel. That was something I asked about a few days ago, and didn't get any responses suggesting that anyone thought it was likely to happen. We would need wholesale changes everywhere in the protocol to support concurrent queries: answers and errors coming back would have to be tagged to indicate which query they apply to. The lack of a tag in the cancel message isn't the controlling factor. In the current system architecture, much the easiest way to execute concurrent queries is to open up more than one connection. There's nothing that says a frontend process can't fire up multiple backend processes. I think this is probably sufficient, because I don't foresee such a thing becoming really popular anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: