DGPickett wrote:
> If you have to change calling code to access Postgres, it violates the
> original promise of JDBC: use me and be portable.
JDBC in general failed that requirement a long time ago, I'm afraid.
Whenever I'm writing a JDBC client, I invariably end up with a strategy
object that's customized for each RDBMS target. About the only thing
that is truely portable is the overall infrastructure of
Connection/PreparedStatement/ResultSet etc.
Anyway, if JDBC is meant to be a portable adaptor to existing RDBMSes,
then it should provide a superset of existing capabilities that degrades
nicely when some are not available on a particular RDBMS. It
demonstrably doesn't do that in this case.
You seem to consider JDBC as an end in itself, rather than just another
interface target to adapt an existing DB to. I don't think it's
reasonable or expected for the existing core server to jump through
hoops and change behavior solely for the sake of what the JDBC interface
happens to want. Obviously, if there's some extra data that's easy for
the server to provide, that's a good thing - and in fact we got a lot of
extra metadata in the v3 protocol specifically to help out JDBC. But it
does not seem to be easy (or even universally possible) for the server
to give us the metadata in the limited form that the JDBC interface
expects here.
Again, I ask: Do you have a better suggestion for how the JDBC driver
should handle this case, given the data it gets from the server?
-O