Hi, Mateusz.
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.
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.
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. Best regards. HF 23.09.2013 18:46, Mateusz Loskot wrote:
Hi,
I'm going to ask question about how the current Spatial Extensions are implemented. I have spent some time reading the source code in the current trunk (spatial.h|cc, gcal*.h|cc, related Field and Item definitions, etc.), so I have a rough understanding of the overall structure, how the geometry data types are implemented and exposed to SQL, how the spatial functions are defined and registered. I did not looked into details of implementation of geospatial algorithms, but that's too low level for the question I'm going to ask.
Initially, I was going to ask very detailed question, listing all the relevant code definitions and asking separately about each of them, but that's not necessary at this stage, I think.
Instead, I'm going to simplify and ask about the bigger picture, more about MariaDB extensions API:
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.)?
2. Is it possible to implement Spatial using User-Defined Functions (UDF) defined in shared binary?
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.
Best regards,