It’s true that you can’t define a GEOMETRY column in a foreign table. But you can define a VARCHAR column and apply the ST_GeomFromText to it, or if you want a point you can define a pair of DOUBLE columns and apply the ST_Point function.
In essence, our implementation of GEOMETRY is only an in-memory format right now, not an on-disk format. It’s a little less efficient than a native GEOMETRY data type but hopefully over time we will write optimizer rules that push down filters etc. so we don’t literally construct an in-memory geometry object for every row, only the rows we are interested in. Julian > On Nov 27, 2017, at 2:59 AM, Christian Tzolov <[email protected]> wrote: > > Hey there, > > I'm exploring the new Spatial (https://calcite.apache.org/docs/spatial.html) > functionality and i've been trying to figure out what are the minimal > requirements for using it with my custom adapter. > > Following the guidelines i've set LENIENT conformance in my jdbc URL ( > jdbc:calcite:conformance=LENIENT; > model=...my model > > > ) > > But I am not sure how define the GEOMETRY column types? > > Currently my custom Schema/Table factory implementation infers the column > types from the underlaying system's field types. > > So it seems that i need to change my implementation and somehow to hint > which fields needs to be mapped to GEOMETRY types? Or perhaps i can try to > do some expensive casting in SQL? > > Are there any guidelines, examples for using Spatial functionality on 3rd > party (e.g. custom) adapters? > > Thanks, > Christian
