Re: statement caching proof of concept

Dave Cramer wrote:
> This is just proof of concept. More work has to be done to make it build 
> properly and work properly under different jdk's

Isn't there a bunch of statement state (things like fetch size, max 
rows, etc) that have defined defaults and this cache implementation will 
not provide?

The "wrapper" implementation approach suffers from the usual difficulty 
that the "back links" such as ResultSet.getStatement() point to the 
wrong object. It's actually quite a bit of work to get this right..

The cached statements are vulnerable to buggy apps that mutate the 
statement after close, since there's no interception of those methods to 
check whether the wrapper statement has been closed.

What exactly is the performance bottleneck you're trying to avoid by 
having the statement pool? If it's the parse/plan cost, I think Mark's 
suggestion of putting the cache at the protocol level may be simpler. If 
it's overall statement cost, you might be better off with a generic 
wrapper that is not postgresql-specific at all.

-O