agentm
commented
6 years ago Project:M36 supports two methods of implementing extensions:
- Haskell pre-compiled into the binaries (ideal for bridges to Haskell data types)
- runtime-compiled Haskell via GHC-as-a-service (ideal for third-party modules)
Beyond the data types, the success of PostGIS relates to it function ecosystem. Does geos support all the GIS functions you will need?
I think that a PostGIS competitor within Project:M36 is entirely feasible with the current setup with some caveats:
- currently, Project:M36 materializes all data in RAM- this was merely a design choice of convenience and we are working to eliminate this restriction
- aggregates may be unncessarily expensive, though this may be solved by the point above
As long as you can live with that and recognize that you will be exploring new territory, I would be happy to support your endeavors however I can including adding any sort of hooks into the backend you may need.
I think such a project would be a great example of a third party extension!
theobat
I'd be very interested in the possibility of managing geographic data with this project. Haskell does not have native efficient libraries to handle geographic data, but there are bindings to existing c++ ones such as https://github.com/ewestern/geos.
Overall, the most interesting things with postgresql are often contained in extensions (the engine itself is quite good, but its extensibility is key to its success). What's your opinion on extensions for this project, and what's already there for them ?