[
https://issues.apache.org/jira/browse/CALCITE-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817762#comment-17817762
]
Julian Hyde commented on CALCITE-6263:
--------------------------------------
I used string (WKT) as a simple example; binary (WKB) would work just as well.
No objections to a geometry wrapper. (Maybe it could be in interface, with
several possible implementations, such as WKT, WKB and the JTS Geometry object.
It should be immutable.)
> Discuss the coupling of Calcite with JTS
> ----------------------------------------
>
> Key: CALCITE-6263
> URL: https://issues.apache.org/jira/browse/CALCITE-6263
> Project: Calcite
> Issue Type: New Feature
> Components: jdbc-adapter
> Reporter: Bertil Chapuis
> Priority: Major
>
> In order to push ST functions down to Postgis in the JDBC adapter, it is
> necessary to register a type family for geometries in
> [RelDataTypeFactoryImpl.java|https://github.com/apache/calcite/pull/3668/files#diff-0fa7bd8b0354c8a4c331efa4107242e49c5d521f31adbb71388bcbc9acb7a384].
> This changes increases the coupling of Calcite to a geometry library such as
> JTS.
> As this is an architectural change, a few options can be considered:
> # Accepting the coupling of Calcite with JTS.
> # Introducing an abstraction for geometry libraries in Calcite.
> # Using reflection to register the type family only if JTS is available in
> the classpath.
> Personally, I have a preference for options 1 and 3. Option 3, which is
> currently implemented in
> [CALCITE-6239|https://github.com/apache/calcite/pull/3668] has little impact
> on the current behavior. Option 2 would introduce some additional complexity.
> For context, here is a
> [link|https://github.com/apache/calcite/pull/3668#discussion_r1486925458] to
> the original discussion.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
