Skip site navigation (1) Skip section navigation (2)

Re: setObject(...) with native Java arrays like String[] ?

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: John Lister <john(dot)lister(at)kickstone(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: setObject(...) with native Java arrays like String[] ?
Date: 2012-08-24 02:26:49
Message-ID: 5036E669.5040806@ringerc.id.au (view raw or flat)
Thread:
Lists: pgsql-jdbc
On 08/24/2012 02:16 AM, Dave Cramer wrote:
> Well my personal guidelines would be as follows
>
> 1) Has to come with a test case
> 2) If it requires docs it needs those as well
> 3) Don't change the format of the code
> 4) Performance is important ( not sure exactly what that means )
>
> Lastly how to determine if it is a good idea to accept it? I'd like to
> see more discussion from the group, voting would be one way.
> However as I said some very large companies use this as I said. Just
> because it satisfies your itch doesn't make it a good idea for
> everyone else.

I'd want to add:

- Doesn't break major existing users. A test suite that uses JPA and 
Hibernate and/or EclipseLink would make sense, and if I'm lucky I'll 
have time to work on that sometime in the next 100 years or so...

- Improves or preserves the existing level of JDBC compliance. If it's 
nice but non-compliant, it IMO isn't acceptable. Same policy as the main 
server re SQL standards, really.

- Fits within the existing JDBC interfaces and specs where possible; 
extensions should have to jump a higher bar. If it is an extension, it 
should mirror extensions from other drivers/vendors if possible.

- Builds with Java 1.5 (ugh, but it'll be time for 1.6 soon).

--
Craig Ringer


In response to

pgsql-jdbc by date

Next:From: carmentl12Date: 2012-08-24 18:02:49
Subject: Problem with client_encoding UTF8
Previous:From: Craig RingerDate: 2012-08-24 02:23:05
Subject: Re: setObject(...) with native Java arrays like String[] ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group