Re: statement caching patch from Laszlo Hornyak for review

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

In response to

Responses

Browse pgsql-jdbc by date

  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