+++ This bug was initially created as a clone of Bug #51239 +++

Some of the additional DB overhead introduced by the fix to bug 47520 has been mitigated, see bug 51239.

But some overhead remains: the code still reads all columns, even if it does not need all of them, and caches the whole row.

This was done to follow restrictions in baseline ODBC (can read columns only once and only in strictly monotonic column order). This is especially expensive for JDBC, since each column read is a JNI call, crossing the C++/Java barrier, and this is expensive.

So as not to punish backends (database access APIs) that do not have such restrictions, the code touched by the fix to bug 47520 should be pushed to backend-specific code:

1) Provide a generic / fast one that assumes modern behaviour,
   that backends can just use.

2) ODBC (and other weak backends, if any) should override it with
   safer / slower code, that is the "read whole row, cache whole row".
   That safer/slower version can *also* be provided by the generic layer
   and just instantiated by the backend.

   Even ODBC could interrogate the driver's capabilities and use
   the fast method if the browser supports out-of-order column retrieval
   and/or other useful extensions.
   (but pay attention to the problem of SQLGetData returning "no more data"
   for variable-length data).
   That opens another can of worms, which is that drivers lie on their
   capabilities (in either direction: report too little or too much
   capabilities).

See discussion in http://lists.freedesktop.org/archives/libreoffice/2012-July/035387.html