Yes, we should be returning “” rather than null.
(Not an excuse, but that method is so old that I suspect that the authors of
JDBC were still thinking in terms of ODBC. In C it’s difficult to return a
null, it’s easier to return an empty string.)
Julian
> On Jan 6, 2020, at 7:03 PM, Juan Pan
FYI.
The following information comes from `java.sql.ResultSetMetaData`.
/**
* Gets the designated column's table name.
*
* @param column the first column is 1, the second is 2, ...
* @return table name or "" if not applicable
* @exception SQLException if a
Hi Julian,
You’re right. From my tests, since “a” is not from table test,
getTableName(columnIndex) returns `empty string` from MySQL and H2 databases,
and `null` from calcite. It makes sense.
The scenario happened to me is that some of third-part applications or
open-source projects would
In the JIRA case, I’ve proposed a rewrite that I think would allow us to
implement GROUP_ID without any changes to Aggregate.
> On Dec 31, 2019, at 12:07 AM, Feng Zhu wrote:
>
> Recently, we encounter a problem caused by some inconsistency query results.
> After some investigations, I find the
Andrew Pilloud created CALCITE-3714:
---
Summary: BitString.createFromBytes reverses order of the bits in
each byte
Key: CALCITE-3714
URL: https://issues.apache.org/jira/browse/CALCITE-3714
Project:
I agree, let’s drive from the SQL standard or what other databases do, rather
than driving from what Java has. If other DBs support a particular function,
and are consistent, then that is a good argument for adding it to Calcite.
I rather like the way that we categorize extensions into
Most of those functions are not mentioned in SQL standard 2011. So It's a
good idea to decide if implementing a function by checking if other systems
provide it. Thanks for putting those together into the spreadsheet!
-Rui
On Sun, Jan 5, 2020 at 11:03 PM Chunwei Lei wrote:
> Thanks for
Is it worth mentioning that we have a new PMC chair? (Of course you’re too
modest to mention it.)
I am proud of the fact that we change the chair annually, and are now on our
fifth (distinct) chair. Orderly transfer of power is a mark of a stable
democracy.
> On Jan 5, 2020, at 2:29 AM,
JDBC table names and column names are of limited use. They tell you where a
particular column comes from, and your “a” column does not come (directly) from
a table. I think you’ll find that Calcite is implementing the JDBC standard
correctly, and is consistent with other databases.
What do
Vladimir Sitnikov created CALCITE-3713:
--
Summary: Remove column names from Project#digest
Key: CALCITE-3713
URL: https://issues.apache.org/jira/browse/CALCITE-3713
Project: Calcite
Vladimir Sitnikov created CALCITE-3712:
--
Summary: Optimize lossless casts in RexSimplify: CAST(CAST(intExpr
as BIGINT) as INT) => intExpr
Key: CALCITE-3712
URL:
Oh, there's org.apache.calcite.rex.RexUtil#isLosslessCast which is used in
MaterializedView*Rule, so I'll try adding that to RexSimplify
Vladimir
Hi,
I'm analyzing testJoinMaterialization5 which times out after my recent
Calcite fixes.
I'm inclined that the bug is with MaterializedViewJoinRule(Filter).
The case is as follows:
materialized view:
select cast("empid" as BIGINT) from "emps"
join "depts" using ("deptno")
input SQL:
select
Did we decide a time yet ?
On Sun, Dec 22, 2019 at 11:31 AM Muhammad Gelbana
wrote:
> Here are my availability times in case we won't use doodle. Do you think
> it's useful to record and save those meetings ?
>
> Mohamed
> ==
> Option 1: Sun-Thur 15:00-19:0
> Option 2: Fri 12:00-19:00
>
Ruben Q L created CALCITE-3711:
--
Summary: Correlate should override estimateRowCount
Key: CALCITE-3711
URL: https://issues.apache.org/jira/browse/CALCITE-3711
Project: Calcite
Issue Type:
15 matches
Mail list logo
