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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-jdbc by date

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