Understood. But how big is the risk those people that do not go with pure JDBC but choose to go with native PostgreSQL
driverclass are not clever enough to abstain from picking implementation details? And how problematic is it, when they
actuallyuse those classes?
BTW, in the long term would be a good idea to contribute the needed changes to JDBC by becoming an official JSR EG
member. Dave already applied AFAIK.
-----Original Message-----
From: Vladimir Sitnikov [mailto:sitnikov.vladimir@gmail.com]
Sent: Donnerstag, 23. Juli 2015 20:11
To: Markus KARG
Cc: List
Subject: Re: [JDBC] Public vs internal APIs
>I mean, people shall code against java.* API, not against org.postgresql implementation. If we make this clear in the
JavaDocs,maybe it is enough?
On contrary, we do want to expose advanced stuff PostgreSQL has.
For instance: "timestamp with time zone". Not everybody can upgrade to java 8.
Another example is COPY command: JDBC has no standard way of doing that.
We have to define org.postgresql interface for it.
JDBC is not that good for async operations either: logical decoding, notify, etc, so again some org.postgresql might do
muchbetter job here.
For regular stuff like "send int here and there", everybody should use regular JDBC, however, there are cases when
non-JDBCusage is intended.
Vladimir
