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
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[] ? |