+1 for full charset support.
There may be multiple changes to make, not only related to literals but
also to type system, casts, (jdbc) binary protocols etc.
I'd like to propose some design ideas since I'm from a CJK country and
we've already tackled most of Calcite's charset issues.
On Thu, Nov
Hi,
You could use optional charset literal here. E.g.,
> upsert into t1(c1,c2,c3) values(_UTF16'中文',2,2);
For some reason Calcite currently only support UTF-16 for Unicode. Here
CALCITE-2619 is an on going work to support more charsets like UTF-8,
GB2312 and GBK.
On Wed, Nov 7, 2018 at 5:30 PM
All fair points. Thanks for the insight :)
--
Michael Mior
mm...@uwaterloo.ca
Le ven. 9 nov. 2018 à 14:03, Julian Hyde a écrit :
> I’m not very impressed with this work. A DSL for query transformation
> rules has been tried in the past - all the way back to EXODUS[1] - but
> there are so many c
I’m not very impressed with this work. A DSL for query transformation rules has
been tried in the past - all the way back to EXODUS[1] - but there are so many
complexities to deal with that it is better to write your rules in a full
programming language.
They don’t explicitly talk about relatio
Hongze has also just contributed WITHIN GROUP [1] - basically the ability for
aggregate functions to operate on sorted input, the same way that many window
functions do. So, thanks for the great contributions.
But also, I want to thank our committers (Michael, Vladimir). Shepherding
complex PRs
Great addition! Many thanks to all (Hongze, Michael, Vladimir) of you :)
Στις Παρ, 9 Νοε 2018 στις 5:44 μ.μ., ο/η Michael Mior
έγραψε:
> Just wanted to put out a thanks to Hongze on this thread for the numerous
> changes that went into the initial pull request which has now landed! Happy
> to se
The Apache Jenkins build system has built Calcite-Master (build #959)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/959/ to
view the results.
Just wanted to put out a thanks to Hongze on this thread for the numerous
changes that went into the initial pull request which has now landed! Happy
to see this completed.
--
Michael Mior
mm...@apache.org
Le mer. 29 août 2018 à 16:11, Julian Hyde a écrit :
> Somehow I missed this… we have a p
Hi,
if I understand your question correctly, you want to "transform" a SQL
Statement into calls to pandas, is this right?
If so, you could implement a specific Call Convention, see [1].
By implementing your own Implementor you could then build together your pandas
call.
Julian
[1]
https://gi
Hi all,
Is it possible to use Pandas as a backend for computing the operations
parsed from SQL statements? I'm researching a way to parse SQL into Pandas
operations and maybe Calcite would be a way to do that.
Thanks
They're not using Calcite. Their code base is in Go and they wrote their
own in Go. If you read the blog post, they describe a DSL they built for
expressing optimizer rules which is kind of nice although not terribly
different from what we're doing with Calcite.
--
Michael Mior
mm...@apache.org
I guess it's not a volcano planner but a cascades[1] style planner. Calcite
is the volcano style. Some common notion like 'Memo', 'Group',
'Transformation' of Cascades planner can be found from their planner. The
systems like gporca ,prestodb (maybe including the CockroachDB ) implement
the cascade
Dawid Wysakowicz created CALCITE-2664:
-
Summary: Change default option for AFTER MATCH SKIP to SQL
standard compliant one
Key: CALCITE-2664
URL: https://issues.apache.org/jira/browse/CALCITE-2664
Thanks for sharing this Michael!
I had a look on their blog post but I didn't notice something really novel.
It gives me the impression that they re-implemented a Volcano-style
optimizer like the one of Calcite.
Out of curiosity, are they using Calcite, or they really built everything
from scratc
14 matches
Mail list logo
