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
>
>