Problem: lack of distinct options to process data #215
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yrashk
force-pushed
the
prolog
branch
3 times, most recently
from
64eb362
to
795c1a2
Compare
Your choices are either SQL with all its expressive power, potential parallelization, optimizations, etc. or a few imperative or functional languages, starting from PL/pgSQL. Other approaches are not quite available. Solution: provide a proof-of-concept integration of Prolog It uses SWI-Prolog as the implementation of choice. It's not the fastest one, or ISO-compliant. But it does integrate relatively well and packs a lot of features. It's actively developed and has a good community. Being a relative newcomer to Prolog, I can't tell if this is a perfect decision long-term, but it does make sense now. Why Prolog? As I was working on Postgres package management, I ended up choosing Prolog as the language for describing constraints and rules for building packages in varieties of configurations and settings. And since I was integrating it with C codebase, I thought: "hey, maybe this is a good candidate for a language in Postgres!". It certainly allows to process data from the database in a different, unique, and valuable way. This current implementation is incomplete but shows the general idea and even implements a sandboxed (trusted) version of the language using `library(sandbox)`.
Solution: ensure we use older API on Postgres 13
This is limiting their usefulness. Solution: implement basic support for these Note that it currently only supports "materialize" method mostly for simplicity's sake. It's possible to do the function call convention by saving the engine in the context. Can be done at a later point.
It's not describing and everything and describes something it doesn't do (printing). Solution: adjust the commentary to reflect the reality
Mostly because we don't check the results of some functions. Solution: make them all required to pass successfully I wrote a `PL_require(cond)` macro for this.
Not sure if they are reported correctly if set is not expected. Solution: write a test
It does something "funny" when it encounters such types: it creates an `unsupported` atom. This is not a good behaviour. Solution: raise an exception instead
Solution: ensure PL_require is called by its correct name It was originally called PL_iff but was then renamed using IDE and it didn't rename the #ifndef-outed name.
This is because initialization is delayed until first invocation. Solution: initialize with the extension in _PG_init
This is less than ideal as the output of it is less predictable. Solution: just throw an error
This will make it harder to discover it. Solution: list it
Solution: fix the target of the comment
Solution: switch to the development branch They are generally quite stable and pack a lot of new features that can be useful.
Solution: update to a newer one
In particular, it uses `success` field that has been removed. Solution: use `error` alone
Solution: switch it to migrations
When building in isolation, it fails to load omni_prolog_stub: ``` open_shared_object/3: dlopen(omni_prolog_stub.so, 0x0001): tried: 'omni_prolog_stub.so' (no such file) ``` Solution: ensure the target that requires it depends on it
Solution: upgrade to 9.1.21
The error reporting suggests `$omni_load_code/2` could not be found. Solution: ensure we're not deallocating the path to the library when handing it off to SWI Prolog's initializer.
Solution: ensure we allocate the results in the correct context Results were previously allocated in (primarily) "SPI Proc" context which was deleted before the return from the language handler.
Solution: start writing tests Currently, dynamic predicates are shared. Static aren't.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Your choices are either SQL with all its expressive power, potential parallelization, optimizations, etc. or a few imperative or functional languages, starting from PL/pgSQL.
Other approaches are not quite available.
Solution: provide a proof-of-concept integration of Prolog
It uses SWI-Prolog as the implementation of choice. It's not the fastest one, or ISO-compliant. But it does integrate relatively well and packs a lot of features. It's actively developed and has a good community. Being a relative newcomer to Prolog, I can't tell if this is a perfect decision long-term, but it does make sense now.
Why Prolog?
As I was working on Postgres package management, I ended up choosing Prolog as the language for describing constraints and rules for building packages in varieties of configurations and settings. And since I was integrating it with C codebase, I thought: "hey, maybe this is a good candidate for a language in Postgres!". It certainly allows to process data from the database in a different, unique, and valuable way.
This current implementation is incomplete but shows the general idea and even implements a sandboxed (trusted) version of the language using
library(sandbox).