Details
Description
Here is my problem, and it comes out of work for the Teradata jdbc datastore. In Teradata geometries are stored as blobs in the database. When a query such as the following happens:
SELECT the_geom FROM table ....
The jdbc driver does not return the actual geometry data but only a locator or identifier for it. And the jdbc code to access it is:
Blob b = rs.getBlob("the_geom");
Pretty standard. The problem is though that the jdbc driver has to make another trip to the server to retrieve the actual data for the blob. Which is expensive to do.
The workaround in teradata to get the blob data inline is to do a cast like the following:
SELECT CAST(the_geom AS VARBINARY(16000)) FROM table ....
Which forces the jdbc driver to coerce the blob into a byte array and return it inline, forgoing the need for a second query. Then the jdbc code to access is simply:
byte[] b = rs.getBytes("the_geom");
Now obviously this falls apart for large geometries since they can't be coerced into the byte array since it is too large. In this case the call to rs.getBytes() will simply return null.
So long story short my idea is to do this:
SELECT the_geom, CAST(the_geom AS VARBINARY(16000)) AS geom_inline FROM table ....
And then the access code looks like this:
//first check for the inline geometry byte[] b = rs.getBytes("the_geom_inline"); if (b == null) { //fall back to retrieving the blob from the server Blob blob = rs.getBlob("the_geom"); ... }
So the idea is to support the dialect smuggling additional columns into a SELECT.