| From: | Dave Cramer <pg(at)fastcrypt(dot)com> | 
|---|---|
| To: | Oliver Jowett <oliver(at)opencloud(dot)com> | 
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-jdbc(at)postgresql(dot)org, Kris Jurka <books(at)ejurka(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com> | 
| Subject: | Re: Caching driver on pgFoundry? | 
| Date: | 2007-09-08 22:50:59 | 
| Message-ID: | 844D9561-315B-4A90-93AA-F2940BB3C374@fastcrypt.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-jdbc | 
On 8-Sep-07, at 5:38 PM, Oliver Jowett wrote:
> Dave Cramer wrote:
>> On 7-Sep-07, at 9:13 AM, Oliver Jowett wrote:
>>>
>>> What is the implementation advantage of making statement pooling  
>>> part of the main driver? There are maintenance issues which count  
>>> *against* it being part of the driver so you need to provide a  
>>> good reason to include it.
>>>
>> Well, it has to be maintained regardless of where it is. So how  
>> does that make any difference ?
>
> Err if it is part of the main driver it needs to be maintained as  
> part of the main driver and will follow the main driver's release  
> cycle. Others have commented on the same thing. It also increases  
> the complexity of the main driver, making it harder for a  
> particular person to maintain the whole thing.
>
> I'm going to ask again: What is the implementation advantage of  
> making statement pooling part of the main driver?
>
It's simpler, there's about half a dozen classes and one if statement  
as opposed to implementing the Connection and Statement interfaces  
for 3 versions of  jdbc and yet another build system that does the same.
Dave
> -O
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Jowett | 2007-09-08 22:57:33 | Re: Caching driver on pgFoundry? | 
| Previous Message | Oliver Jowett | 2007-09-08 21:44:49 | Re: Caching driver on pgFoundry? |