Re: Public vs internal APIs

Understood. But how big is the risk those people that do not go with pure JDBC but choose to go with native PostgreSQL driver class are not clever enough to abstain from picking implementation details? And how problematic is it, when they actually use 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(dot)vladimir(at)gmail(dot)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 much better job here.

For regular stuff like "send int here and there", everybody should use regular JDBC, however, there are cases when non-JDBC usage is intended.

Vladimir