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