From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | Csaba Nagy <nagy(at)ecircle-ag(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: statement caching patch from Laszlo Hornyak for review |
Date: | 2007-08-02 07:50:11 |
Message-ID: | 46B18CB3.4090708@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Dave Cramer wrote:
> I posted the proof of concept back in June of last year, and again in
> March.
>
> I searched the archives but was unable to find where you voiced this
> opinion ?
It was as a reply to your post last year:
http://archives.postgresql.org/pgsql-jdbc/2006-06/msg00049.php
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kalle Hallivuori | 2007-08-02 08:11:57 | Bulk copy with connection locking patch |
Previous Message | Dennis Thrysøe | 2007-08-02 07:44:02 | LargeObject API |