Do you know how I can get Postgres OR working with Multicorn?
I get this message:
WARNING: unsupported expression for extractClauseFrom
Over email @rdunklau asked for a proposal for implementing these quals that is backwards compatible. My proposal to maintain backwards compatibility is as follows:
Create a new op called "OR_EXPR" or "AST_EXPR".
This op has a value list, and is_list_operator is true.
The value of the boolean in the tuple is ANY, but it doesn't matter.
The value of "field" is either None if that is allowed, or we can select the name of an existing column. Either way, the "field" is unused.
Since people add code for each op individually, their existing code for skipping unhandled ops will just skip this qual because they will see a new op: "AST_EXPR".
The value list is a list of Quals.
The qual performs an OR over all the subordinate Quals.
This approach is nice because existing code can be reused and extended to add the OR_EXPR, and you can recurse.
Over email @rdunklau replied:
"it may be better to offer a separate qual API entirely.
Depending on an attribute defined on the foreign-data-wrapper (QUAL_API = 2)
for example, the qual representation would either be as-is, or be a binary
tree more closely reflecting the internal structure of PostgreSQL expression
trees.
This would allow both to coexist peacefully, while keeping the default of
having everything be simple enough."
Do you know how I can get Postgres OR working with Multicorn?
I get this message: WARNING: unsupported expression for extractClauseFrom
Over email @rdunklau asked for a proposal for implementing these quals that is backwards compatible. My proposal to maintain backwards compatibility is as follows:
This approach is nice because existing code can be reused and extended to add the OR_EXPR, and you can recurse.
Over email @rdunklau replied:
"it may be better to offer a separate qual API entirely.
Depending on an attribute defined on the foreign-data-wrapper (QUAL_API = 2) for example, the qual representation would either be as-is, or be a binary tree more closely reflecting the internal structure of PostgreSQL expression trees.
This would allow both to coexist peacefully, while keeping the default of having everything be simple enough."