Dave Cramer wrote:
> I posted the proof of concept back in June of last year, and again in
> I searched the archives but was unable to find where you voiced this
> opinion ?
It was as a reply to your post last year:
Maybe I should've voiced my opinion more strongly back then..
> Either way, the patch is written in such a way to be very non-invasive
> to the driver, and the code
> will only ever be executed (except for a single if statement) if the
> user enables the feature.
> Can you be more specific about why you want this as a separate module ?
I'd just like to keep the core JDBC driver slim as a matter of
principle. Given that most application servers already have their own
connection pooling and prepared statement caching implementation, and
the fact that there's other stand-alone implementations out there
(Apache DBCP, for example), most people who need the JDBC driver don't
need another connection pool and statement cache.
As a separate module, the pool and the cache could get a wider audience.
You could use it with different databases and JDBC drivers in addition
to PostgreSQL. And it wouldn't be tied to PostgreSQL driver release
cycle, and vice versa.
In response to
pgsql-jdbc by date
|Next:||From: Kalle Hallivuori||Date: 2007-08-02 08:11:57|
|Subject: Bulk copy with connection locking patch|
|Previous:||From: Dennis Thrysøe||Date: 2007-08-02 07:44:02|
|Subject: LargeObject API|