> Would it not be possible to do (1) now and leave the door open to add
> (2) later without breaking existing uses of (1)? That is, I don't see
> why (3) has to carry a risk of non-backwards-compatibility. Surely you
> can design non-overlapping APIs for (1) and (2).
>
> (Obviously, my vote is for (3).)
indeed, from a systems engineering viewpoint, thats the correct solution. (1)
is a sort of COPY RAW function, while (2) is more java-like. OTOH, if
there's no Java standard for a JDBC mechanism like (2), it becomes tougher to
justify.