Hi Julian, Vladimir,
Israel time zone It is not fixed. Formally, you may find different
abbreviations, like IST and IDT. But in real systems, like Postgres, MS
SQL, or Java, this is a single time zone with DST changes.
The following query in Postgres will return 21:00, 21:00, 22:00 for 24, 25,
Israel Standard Time is fixed at UTC+2. It does not observe daylight
savings time. So maybe your wall clock should have been in the
'Asia/Jerusalem' time zone rather than Israel Standard Time.
On Wed, Mar 31, 2021 at 12:23 PM Vladimir Sitnikov
wrote:
>
> >Let me provide the exact example
>
>
Julian Hyde created CALCITE-4562:
Summary: Improve simplification of "expression IS TRUE"
Key: CALCITE-4562
URL: https://issues.apache.org/jira/browse/CALCITE-4562
Project: Calcite
Issue
>Let me provide the exact example
Sorry for not being clear.
As far as I understand, Avatica means "Java JDBC API" or "something like Go
API".
Could you please provide a test case via Avatica API (e.g. JDBC API) along
with the actual and expected result?
For example,
Hi,
Thank you for your feedback. Let me provide the exact example of when the
problem happened. Consider the date 2020 Oct 25 in Israel Standard Time
[1]. There was DST end at this date. This date represents exactly 18560
days since 01 Jan 1970. When there was 2020 Oct 25 00:00 IST, it was 2020
Stamatis Zampetakis created CALCITE-4561:
Summary: Wrong results for plan with EnumerableHashJoin (semi) on
nullable colunms
Key: CALCITE-4561
URL: https://issues.apache.org/jira/browse/CALCITE-4561
Stamatis Zampetakis created CALCITE-4560:
Summary: Wrong plan when decorrelating EXISTS subquery with
COALESCE in the predicate
Key: CALCITE-4560
URL: https://issues.apache.org/jira/browse/CALCITE-4560
Julian>you should be able to come up with a test case
Julian>against a reputable database (e.g. PostgreSQL
pgjdbc committer here :)
There are timezone-related tests in
Thanks for taking this on.
There are two ways of handling sub-queries: one is to have
SqlToRelConverter expand them during translation, and the other is to
wrap them in RexSubQuery and treat them as scalar expressions until
they are handled by SubQueryRemoveRule. I couldn't tell which approach
