Re: Different behavior bewteen '>' and '='

Hi Julian, Sorry to make you confused about this. Let me try to simplify this discussion. What we are facing now, is the implicit type coercion problem, which is introduced in CALCITE-613 [1] and CALCITE-2302 [2]. These two features behaves differently in the following case: # SQL "select ename

Re: Different behavior bewteen '>' and '='

I’m confused. Is this thread about type derivation, coercion, simplification, or query execution? Those are orthogonal topics, so discussing more than one at a time adds confusion. > On Apr 11, 2022, at 4:54 AM, Benchao Li wrote: > > Hi xiong, > > Thanks for the input. Yes, CALCITE-4993 is

Re: Different behavior bewteen '>' and '='

Hi xiong, Thanks for the input. Yes, CALCITE-4993 is related to this issue. And if we choose #1 or #2, CALCITE-4993 would be solved too. xiong duan 于2022年4月10日周日 16:03写道： > Hi BenChao, > Thanks to bring this up again. I find another relative issue ISSUE-4993 >

Re: Different behavior bewteen '>' and '='

Hi BenChao, Thanks to bring this up again. I find another relative issue ISSUE-4993 about the RexSimplify. Because the EQUALS and NOT-EQUALS Operator uses the *LEAST_RESTRICTIVE* strategy to validate the parameter. Other comparators use the

Re: Different behavior bewteen '>' and '='

Hi all, Sorry to bring this up again. I kind of agree with Stamatis. The behavior for '=' is not only different from '>', but also different from the CALCITE-2302's implementation. '=' in CALCITE-613 do not add 'cast' operator, and this will complicate physical implementation. Even more,

Re: Different behavior bewteen '>' and '='

Hi all, Actually I find it very confusing the fact that > and = behave differently and I would consider this a bug. >From the SQL standard perspective I don't think this is a valid query and as others mentioned it fails in the category of implicit type conversions. My take is that if implicit

Re: Different behavior bewteen '>' and '='

Thank you both for your replies, I will find if there is a better way to solve my problem. Best, Dan Zou > 2022年1月11日 20:33，Vladimir Ozerov 写道： > > Hi, > > If I recall correctly, the SQL standard is mostly silent on how one should > coerce operands. Therefore different systems implement the

Re: Different behavior bewteen '>' and '='

Hi, If I recall correctly, the SQL standard is mostly silent on how one should coerce operands. Therefore different systems implement the coercion at their discretion. Moreover, the type inference might be influenced not only by operands types but by their nature as well. For example, a target

Re: Different behavior bewteen '>' and '='

Yes, this is by design.I believe that the SQL standard set the rules. It’s not that surprising that ‘=‘ has different behavior than ordering-based comparisons such as ‘>’. Consider: given a DATE value d, and a TIMESTAMP value t, it is reasonable to ask ‘is t > d?’ but less reasonable to ask

Different behavior bewteen '>' and '='

Hi community, I recently ran into a problem that when we disable type coercion by SqlValidator#setEnableTypeCoercion(false), there will be two different behaviors between '>' and '=': 1. '>' between character and numeric (e.g. '1' > 1), the character will be implicitly converted to numeric 2.