hi Tanner,
Thank you very much for your reply.
In the ISO/IEC SQL standard, scalar functions can be classified into the
following types:
1. String functions: Functions for manipulating string data, such as
CONCAT(), SUBSTRING().
2. Numeric functions: Functions for working with numeric data, such
I don't think it's a bad idea but I'm also not sure whether it's worth the
time and effort of deciding what functions should be grouped together, etc.
Seeing as how methods in that class are mostly (always?) called via
reflection, I think having them in one place is helpful in ensuring
consistent
hi,
I noticed that the code file of the SqlFunctions.java class is getting
larger and larger and the functions are increasing. I think some functions
can be broken down into different function classes to slim down
SqlFunctions. For example: json functions use JsonFunctions, and only
SqlFunctions
Thanks for reaching out, Jerin!
(Jerin and I work together at Google, but I’m wearing my Calcite hat here.)
A Tableau connector is something Calcite has needed for some time, and
in fact there is a Jira case for it [1]. The goals were (1) create a
'vanilla' connector to that Tableau can connect
The taxonomy seems about data stores (one or many) and supported query
languages (one or many). Calcite is ‘many’ in each category, even though it
appears to be one query language (SQL) and no data stores.
TL;DR: I would put it in the ‘polystore’ category. “Query answering” is one of
its
correction:
When compared to the jdbc implementation, which works for me using the
EnumerableConvention.
I see the difference is that the EnumerableProject gets mapped to a
EnumerableCalc.
Mapped to LogicalProject.NONE
When compared to the jdbc implementation, which works for me using the
EnumerableConvention.
I see the difference is that the EnumerableProject gets mapped to a
CalcProject.
Mapped to Project.NONE
Hi Francis,
Yes, my visualization can be found here: https://imgur.com/a/pawHWXf
Kind regards,
Teun Mathijssen
On 2024/01/29 07:52:02 Francis Chuang wrote:
> Hello Teun,
>
> It seems your attachment didn't come through. Can you upload it to imgr
> and link it here?
>
> Thanks,
> Francis
>
> On
Just to clarify: on my previous email I did not mean that any of those
issues in particular were the cause of this problem, but rather that it
could be possible that a similar issue on the JDK that was used to build
the release might be the root cause, but I'm not 100% sure.
In fact, according to
Having a gradle task to ensure that class files are valid bytecode
seems like a good idea. It may not be 100% bulletproof since we yet
rely on another tool/library to perform the verification but still
having an extra check will not hurt if it is lightweight.
It makes sense to enforce a certain
10 matches
Mail list logo
