at sql spec side, I tried to find sth related in
http://jtc1sc32.org/doc/N2301-2350/32N2311T-text_for_ballot-CD_9075-2.pdf,
especially in section 4.6, but nothing is found. If you found sth pls let
me know
On Fri, Feb 17, 2017 at 3:24 PM, hongbin ma wrote:
> hi julian
>
> on postgres I tried tim
hi julian
on postgres I tried timestamp + interval, because it seems timetampadd is
not supported:
https://www.postgresql.org/docs/9.1/static/functions-datetime.html
JIRA title is updated
On Fri, Feb 17, 2017 at 12:51 AM, Julian Hyde wrote:
> On Postgres did you try TIMESTAMPADD or did you try
Zhiqiang He created CALCITE-1644:
Summary: RelToSql for MATCH_RECOGNIZE
Key: CALCITE-1644
URL: https://issues.apache.org/jira/browse/CALCITE-1644
Project: Calcite
Issue Type: Sub-task
Zhiqiang He created CALCITE-1643:
Summary: SqlToRel for MATCH_RECOGNIZE
Key: CALCITE-1643
URL: https://issues.apache.org/jira/browse/CALCITE-1643
Project: Calcite
Issue Type: Sub-task
Zhiqiang He created CALCITE-1642:
Summary: SqlNode validation for MATCH_RECOGNIZE
Key: CALCITE-1642
URL: https://issues.apache.org/jira/browse/CALCITE-1642
Project: Calcite
Issue Type: Sub-ta
Thank you Julian for the intro, and also thanks to the PMC for inviting me.
I currently work at Dremio, and these past weeks/months I have been
focusing on improving our JDBC/ODBC experience, but I also have some fun
poking to the other parts of Calcite and Avatica, and hopefully I'll expand
the r
Zhiqiang He created CALCITE-1641:
Summary: MATCH_RECOGNIZE syntax support for calcite
Key: CALCITE-1641
URL: https://issues.apache.org/jira/browse/CALCITE-1641
Project: Calcite
Issue Type: Su
Congrats Laurent!
On Thu, Feb 16, 2017 at 2:34 PM, Julian Hyde wrote:
> On behalf of the PMC I am delighted to announce Laurent Goujon as a new
> Calcite committer. Laurent has been rounding out the product in several
> areas, including support for the standard set of built-in functions, and
> i
Calcite differs from Catalyst in many ways. First of all, Catalyst is
essentially a heuristic optimizer, while Calcite optimizers often combine
heuristics and cost-based optimization. Catalyst pushes down predicates and
projections to most data sources, while Calcite can often push down full
qu
Heya,
I've been using Spark recently and have stumbled across a couple surprising
bugs/feature gaps. It got me curious about how Calcite would handle the
same scenarios. Basically, I'm wondering if Calcite would handle these
scenarios directly or if it would defer to the underlying runtime. I.E.,
On behalf of the PMC I am delighted to announce Laurent Goujon as a new Calcite
committer. Laurent has been rounding out the product in several areas,
including support for the standard set of built-in functions, and improving
JDBC compliance in Avatica. Please give Laurent a warm welcome to the
On behalf of the PMC I am delighted to announce Jess Balint as a new Calcite
committer. Jess has been making a steady stream of improvements to RelBuilder
and the RelToSqlConverter, making them more usable and higher quality. Please
give Jess a warm welcome to the project!
Jess, If you would li
On behalf of the PMC I am delighted to announce Gian Merlino as a new Calcite
committer. Gian is one of the main developers of Druid, and has been adding SQL
support to Druid over the last few months. The SQL support is based on
Calcite’s Druid adapter, and he has been contributing back improvem
Playing with Postgres a bit it looks like its array types can behave in
Druid-y ways. The three queries below are what Druid would do with "select"
and "groupBy" queries against a multi-value column. I'm not sure how
standard this behavior is or if Calcite does the same thing, but this seems
like a
Yes I have, although it's disabled in Druid for now because of a bug:
https://issues.apache.org/jira/browse/CALCITE-1601. I haven't had time yet
to look into why that's happening.
Gian
On Thu, Feb 16, 2017 at 1:59 PM, Julian Hyde wrote:
> Yes, exactly.
>
> FLOOR( .. TO timeUnit) is non-standard
Jess Balint created CALCITE-1640:
Summary: SqlImplementor (RelToSql) doesn't handle join cond same
as filter
Key: CALCITE-1640
URL: https://issues.apache.org/jira/browse/CALCITE-1640
Project: Calcite
Yes, exactly.
FLOOR( .. TO timeUnit) is non-standard, if that matters.
Have you seen DateRangeRules (and DateRangeRulesTest)? The work you are doing
would fit in perfectly.
Julian
> On Feb 16, 2017, at 1:28 PM, Gian Merlino wrote:
>
> Fair enough, so I guess the way to do that without usin
Fair enough, so I guess the way to do that without using FLOOR would be:
CAST(CAST(ts AS DATE) AS TIMESTAMP) + EXTRACT(HOUR FROM ts) * INTERVAL
'1' HOUR
(Casting to date and back to timestamp to do a poor mans' floor to day)
Gian
On Wed, Feb 15, 2017 at 11:48 PM, Julian Hyde
wrote:
> Funny
On Postgres did you try TIMESTAMPADD or did you try timestamp + interval? I ask
because if we fix this, we are going to have to change the behavior of
timestamp + interval.
Also please change the JIRA case subject to something more descriptive.
For the SQL standard, search for "ISO/IEC 9075-2”
Hi Julian,
thanks a lot for your thoughts and advice!
I'd like to give a bit more background on why we were thinking about system
attributes and why we did not want to allow changing the time attribute.
In Flink, the event-time attribute is handled as meta data of each record.
Users do not have
hongbin ma created CALCITE-1639:
---
Summary: issue for timestampadd month
Key: CALCITE-1639
URL: https://issues.apache.org/jira/browse/CALCITE-1639
Project: Calcite
Issue Type: Bug
Re
Hi Julian
Thanks for you reply.
I have confirmed on postgresql, it behaves exactly as mysql.
For ansi SQL 92 I could find http://www.contrib.andrew.cmu.edu/~shadow/sql/
sql1992.txt, however for SQL 2011 I can't find a counterpart source. Can
you please kindly show me a link? just to make sure we
22 matches
Mail list logo
