Re: [Maria-developers] [Spatial] On current implementation approach

Yes, but my question is not really about location of computational geometry bits, but about the data management: SQL data type for geometry objects, input/output routines.

That what i meant. That code do not use any Field data structures.

1. Field is the only place that defines GEOMETRY type (and there is no CREATE TYPE support)

For the Field the GEOMETRY is just the string of bytes.

2. UDF prototypes will use of GEOMETRY in their prototypes to declare input/output parameters then I couldn't understand how it is possible to remove geometry definitions from Field and other internal definitions.

That what i guess i missed in your question. Yes if we remove the GEOMETRY from the server, there's no way to specify the GEOMETRY type for the UDF. Though instead we can specify strings as parameters and treat them as GEOMETRY inside. Best regards. HF 24.09.2013 4:38, Mateusz Loskot wrote:

On 23 September 2013 22:10, Alexey Botchkov wrote:

...

...

1. Is it possible to implement MariaDB extensions like Spatial (custom type + set of functions) without such a tight coupling with the internal implementation of the type system (without messing Field class with geometry types directly, etc.)?

Yes, it is possible. The core algorithms are separated from the Field structure and any other database internals. They are placed in sql/gcalc_slicescan.cc and sql/gcalc_tools.cc files. Yes, but my question is not really about location of computational geometry bits, but about the data management: SQL data type for geometry objects, input/output routines.

Due to my lack of experience with MariaDB/MySQL UDF, I simply assumed that if: 1. Field is the only place that defines GEOMETRY type (and there is no CREATE TYPE support) 2. UDF prototypes will use of GEOMETRY in their prototypes to declare input/output parameters then I couldn't understand how it is possible to remove geometry definitions from Field and other internal definitions.

But, I've just found this project [1] with extra spatial UDFs, so I think I understand the UDF protocol regarding I/O arguments would not require explicit GEOMETRY type making it possible to move Spatial Extensions completely out of built-ins (trunk/sql/ files).

[1] https://github.com/krandalf75/MySQL-Spatial-UDF

...

...

2. Is it possible to implement Spatial using User-Defined Functions (UDF) defined in shared binary?

The spatial functions/operations can be implemented with UDF, but that makes query optimization and using Spatial keys problemmatic. So, for real use case, the idea I brainstormed above would not make sense. Unless, there is workaround for those problems you mean.

...

...

3. What is the reason behind using Well-Known-Binary (WKB) stream of bytes to transport geometry values into/from functions? Is it due to limitations of MariaDB type system where String is the only universal carrier for complex data? This concern is related to necessity of encoding/decoding WKB when chaining spatial function calls, and possibilities to avoid it.

The reason was mostly historical. It was sufficient for the first implementations of the Geometry field types and somewhat convenient as we don't need to perform conversions when we need to import/export features in their WKB representation. But yes, that format is inefficient and difficult to handle properly. I plan to get rid of it internally - only support importing-exporting it. I roughly understand, but how do you plan to pass geometry data around, in what format?

AFAIU, it is not possible to pass user-defined types into/from SQL functions, so geometries would have to be passed as String objects anyway, wouldn't they? IOW, there are only 3 types available (integer, real, string), so String is the only one usable to pass geometry objects around, regardless of actual encoding format, WKB, WKT, any other binary stream...

It means, that if I want to pass geometry to my_foo UDF:

MSUDF_API char* my_foo(UDF_INIT *initid,UDF_ARGS *args, char *buf, unsigned long *length, char *is_null, char *error);

the only option available is to make geometry into a kind of stream of bytes and passed as one of args item. So, a kind of serialising/deserialising is in fact unavoidable.

Is my understanding correct?

Best regards,