I think there might be an another approach; by making it possible to define
safetiness of an operator - going back to the first example and considering:
SELECT e.name
FROM emp e
INNER JOIN dep d ON e.deptno = d.deptno
WHERE (10 / e.empno) = 1
and the pushed down version:
SELECT e.name
FROM (s
Thanks for logging this. I agree that it’s not high priority. I added some
commentary about related bugs.
> On Oct 7, 2022, at 9:07 AM, Stamatis Zampetakis wrote:
>
> I just logged https://issues.apache.org/jira/browse/CALCITE-5315 but I am
> not planning to work on this sometime soon.
>
> Bes
I just logged https://issues.apache.org/jira/browse/CALCITE-5315 but I am
not planning to work on this sometime soon.
Best,
Stamatis
On Fri, Feb 18, 2022 at 10:56 PM Stamatis Zampetakis
wrote:
> Thank you all for the feedback.
>
> I will do a small research about the proper term to use for func
Thank you all for the feedback.
I will do a small research about the proper term to use for functions that
might throw / never throw and log a JIRA to move the discussion further.
@Viliam : Note that the problem you mention, although similar, is not
exactly the same as the one I brought up now.
I have observed this issue years ago in well-known databases. My case was
much simpler:
data
recordType:int value:text
- --
0 1
1 a
SELECT *
FROM data
WHERE recordType='1' AND CAST(value AS INT)<10
SQL is declarative, and unlike procedural language
You should definitely log a bug, even if there are no plans to fix it. It is a
violation of the standard, and therefore it is a bug, and therefore we should
document that it exists.
Can you do some research on the right terminology. You use the term ‘unsafe’. I
think the PL community uses the t
Is it feasible to prevent the filter push down in cases like this ( detect
potential division by zero) ? What other exceptions that could happen?
Should it only push down some filters and preserve the complex filter above
the join?
Regarding a Jira ticket, generating an exception when it should
