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:
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:
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:
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:
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:
And then the access code looks like this:
So the idea is to support the dialect smuggling additional columns into a SELECT.