maria-developers team mailing list archive

[Mateusz Loskot <mateusz@xxxxxxxxxx>]

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,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
"Participation in this whole process is a form of torture" ~~ Szalony