Ares

@slumber @kyukhin @Korablev77 Hey guys, I have the exact situation mentioned above. And I'm using latest release version (2.10.x) Here's my scenario: ``` CREATE TABLE dummy ( pk INTEGER PRIMARY...

I think the library has a better value to have some batteries included (or default implementations), because developers, will eventually implement this, but why should they? Isn't it better to...

You need cache, otherwise you have 2RTTs for each query. Also the Golang stdlib caches the prepared statement and returns a wrapper for u to use.

sure, but that's wasteful, very wasteful. Using a prepared statement once, or a few times is wasting RTTs and computing power on the database server.

Any normal application has around 1-1000 sql queries, which means 1-1000 calls to prepare statement for the entire runtime, every X time (until the db engine expires the prepared statement)....

Yea, ofc. I was argueing the API. The go stdlib forces me to cache it. This lib should not do that, it should atleast provide a default and basic implementation...

Ofc, and we should not, each connection should have its own sync.Map

1-1000 prepare statement calls, per connection

@oleg-jukovec @DifferentialOrange would you guys be OK with accepting a contribution(a PR) on this ?

What about if impl is in the connection pool package? Since prepared statement cache is per connection, we could add caching in the connection wrappers there