Deserialize geometry

[manticore-projects]

Greetings!

This fixes the ResultSet.getString() method for GEOMETRY and fixes #298:

select ST_GeomFromGeoJSON('{
      "type": "Point",
      "coordinates": [30.0, 10.0]}') as p;

since 1.2.2 was shown as:

DuckDBBlobResult{buffer=java.nio.HeapByteBuffer[pos=0 lim=32 cap=32]}

now with the deserialization applied it becomes again

POINT (30 10)

(Beside that I fixed two TIMEZONE related tests that would not work in other timezones (e.g. failed when system timezone is ASIA/BANGKOK).

[staticlibs]

Hi, thanks for the PR! You can fix formatting problems by running:

python ./scripts/format.py

Though I am not sure that adding DuckDBGeometryDeserializer to the driver itself is a good idea, in general we try not to have any extension-specific code in JDBC. I wonder if this logic can go into client app/connector part instead?

[manticore-projects]

Greetings!

Thank you for your feedback. I have applied the formatter.

On the implementation:

• I don't think it belongs to the client because client because client will normally see Object or Blob or String and then simply does not know what to do with it. Also, until 1.2.2 everything was working fine. What broke it is the ResultSet.getString() applying Object.toString() on just everything including the Blob.
  Example: CSVWriter is a handy library to quickly turn a ResultSet into ASCII/CSV to verify the content (in Unit Tests). CSVWriter is of course RDBMS agnostic and uses simple JDBC features only. This worked great with DuckDB 1.2.1 but is broken now for GEOMETRY. Shall every single JDBC tool in the world implement now a special treatment for DuckDB GEOMETRY?

• DuckDB C code has a similar de-serializer, its just not wrapped/ported (and so I provided the port)

• I am not sure, what exactly you mean by connector part

I agree with you that the need for the de-serializer is sub-optimal. But in my understanding, there are only two options:

1. implement the GEOMETRY class in Java (like you did for ARRAY and STRUCT and BLOB)
2. or implement the Deserializer

As far as I see, Option 1) was worse because you either reinvent the wheel or start depending on 3rd party libraries like JTS.

[staticlibs]

@manticore-projects

I am not sure, what exactly you mean by connector part

I meant some kind of intermediate code like org.jkiss.dbeaver.ext.duckdb.model.DuckDBSQLDialect.

I will follow-up on this after 1.3.2 release next week.