Re: WITH HOLD and pooled connections
От | Andrew Dunstan |
---|---|
Тема | Re: WITH HOLD and pooled connections |
Дата | |
Msg-id | 3F34552E.60000@dunslane.net обсуждение исходный текст |
Ответ на | Re: WITH HOLD and pooled connections (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Whew. To the best of my knowledge, JDBC at least doesn't provide any API by which one could discover such a thing anyway, (although I guess a given driver could implement some sort of statement cache with a name lookup mechanism). I guess if it were part of the standards JDBC API we'd have heard calls for its support by now. When you think about it its a nice idea. (You are right - all my prepped statements are used and disposed of within a single use of a connection in a single thread.) OK ... back to logging stuff ... andrew Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>Tom Lane wrote: >> >> >>>Prepared statements would be just as much of a problem. I think the >>>correct answer is simply "don't use those features in a pooled >>>environment". >>> >>> > > > >>Ouch. Double ouch in fact. I'm using prepared statements extensively in >>my current (pooled conn) app. All pure selects. >>Can this be narrowed down a bit? Is it a problem on all query types? >> >> > >The point is just that there's no infrastructure to manage prepared >statements, eg for a thread to discover whether someone has already >prepped a particular statement on the current connection. Evidently >you have set things up so that you don't need to do that. Panic not. > > regards, tom lane > >
В списке pgsql-hackers по дате отправления: