Hello, I don't want the current situation to be disheartening for anybody, especially those who spend significant time on these code changes (Julian, Vladimir). Our common goal is to release 1.27.0 in the best possible conditions so let's try to agree on the plan to move forward. To do this, I think it is important to answer the following questions:
@Vladimir: Can you specify which JIRA issue(s) you would like to see solved for the next release? @all (committers or not): Did you postpone the upgrade to Calcite 1.26.0 due to the problems found by Vladimir? As soon as we have the JIRA ids: @all (committers or not): Do we have somebody willing to work on the issues found by Vladimir? Best, Stamatis On Sat, Nov 14, 2020 at 4:55 PM Julian Hyde <jhyde.apa...@gmail.com> wrote: > Vladimir, > > I’ve reverted your revert. A commit war is no way to proceed. > > Julian > > > > On Nov 14, 2020, at 2:55 AM, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > > I've reverted SEARCH. Sorry for the inconvenience. > > > > Here's the PR that re-adds SEARCH: > > https://github.com/apache/calcite/pull/2263 > > Please feel free to pick it up. I expect certain commits should be > squashed > > (e.g. search should be re-added as a single commit). > > > > I'm not sure I would have time to make it happen. > > > > Frankly speaking, I would suggest we should make SEARCH operator never > > return null. > > In other words, SEARCH(X, [Y, Z]) should be the same as "(X is not > distinct > > from Y) or (X is not distinct from Z)". > > The old semantics was like SEARCH(null, [42]) => unknown, SEARCH(null, > > [null, 42]) => false which results in wrong results in simplification. > > > > "Expand search" might want to receive unknownAs parameter. > > > > Vladimir > >
