Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test 5423 druid #23

Open
wants to merge 36 commits into
base: test-5383-druid
Choose a base branch
from
Open

Test 5423 druid #23

wants to merge 36 commits into from

Conversation

JiajunBernoulli
Copy link
Owner

No description provided.

libenchao and others added 30 commits November 16, 2022 09:13
The MEASURE type is internal. A RexNode expression that
contains a measure and evaluates to an INTEGER will have the
type MEASURE<INTEGER>, using a parameterized SQL type
similar to ARRAY<INTEGER>. But the same measure column, as
seen from SQL, will just have type INTEGER. The
parameterized type helps us keep things straight in the
relational algebra as we apply planner rules.

The AGGREGATE function belongs to the new CALCITE function
library. To use it, add 'lib=calcite' to your connect string.

Add a new validator configuration parameter,
`boolean SqlValidator.Config.nakedMeasures()`. The query

  SELECT deptno, AGGREGATE(avg_sal)
  FROM emp
  GROUP BY deptno

is valid if `avg_sal` is a measure. If `nakedMeasures` is
true, then the following query is a valid shorthand for it:

  SELECT deptno, avg_sal
  FROM emp
  GROUP BY deptno

In the long term, we would like people to feel comfortable
using the latter form. Measures are not necessarily aggregate
functions, but are just expressions whose value depends on
their context (the current GROUP BY key in an aggregate
query, or the current row in a regular query). And we will
generalize measures to analytic expressions, which are not
necessarily just references to measure columns.

But in the short term, setting the `nakedMeasures` flag to
false provides a level of comfort to people (and tools that
generate SQL) who think of measures as aggregate functions,
and think that measures should only be used in `GROUP BY`
queries.

Extend mock catalog with a table that has measure columns.

Add a new Quidem test, measure.iq. It is disabled because we
don't yet have the means to create measure columns in queries
(or views). That is to come in [CALCITE-4496].

Close apache#2965
…ROM operator

Support DateString in RelBuilder.literal(Object).

Close apache#2961
…, if possible

Why:
When rewriting the query for a semi join, the
`JoinOnUniqueToSemiJoinRule` pushes a new project via
`RelBuilder`. This project is *almost* a good copy of the original
`Project` -- it is just missing the field names.

How:
This change uses `RelDataType` of the `Project` to get the field names
for the new `Project` pushed on the `Relbuilder` stack. This is
similar to what is done in `SemiJoinRule#perform`
…AULT instances

Creating new PruneEmptyRule instances with slightly different
configurations (e.g., modify a rule to match FooProject.class instead
of Project.class) is almost impossible for the following reasons:

* ImmutableXXConfig classes are package private;
* Constructors in PruneEmptyRules class are either deprecated or
package private;
* Existing configurations do not provide DEFAULT instances;
* Configuration cannot be obtained from existing rules cause the latter
are declared as RelOptRule (and not RelRule).

Add DEFAULT configuration instances for each rule variant to provide
users an achor point to modify the behavior of a rule and adhere to the
RelRule interface, which requires all configs to have a DEFAULT
instance.

Close apache#2937
…g literal to array literal (enabled in Postgres conformance)

After this change, you can write an ARRAY constructor
followed by a string literal:

  ARRAY '{1,2,3}'

in a connection with Postgres conformance, and it is
equivalent to

  ARRAY [1,2,3]

Also, if you use a string literal in a context where an
array is needed, the string literal is treated as an array
literal. For example,

  SELECT ARRAY [1,2,3] = '{1,2,3}'

is equivalent to

  SELECT ARRAY [1,2,3] = ARRAY '{1,2,3}'

Close apache#2819
The goal is to reduce how often people need to write a
custom subclass of SqlFunction; rather than overriding a
method, they can change the value of a field.

There are one or two changes to tests because the
"MATCH_NUMBER" function had been misspelled "MATCH_NUMBER ".
Add method SqlOperatorFixture.forEachLibrary, to make it
easier to test an operator in several libraries.
… that are already implemented for other libraries

The functions are: MD5, SHA1, GREATEST, LEAST, COSH, SINH,
TANH, FROM_BASE64, LEFT, LTRIM, REPEAT, REVERSE, RIGHT,
RTRIM, SOUNDEX, TRANSLATE.

Close apache#2978
…conformance)

Adjust LeafQueryOrExpr syntax order to ensure that LeafQuery
is processed first. (Seems to be necessary in the Babel
parser only.)

Add isValueAllowed() in BABEL, LENIENT and MYSQL_5 conformance.

Close apache#2985
The JDBC and builtin functions already contain a TIMESTAMPADD
function with three arguments; this change adds a
TIMESTAMP_ADD function with two arguments, consistent with
BigQuery, and enabled if you have 'lib=bigquery' in your
connection options.

Close apache#2998
bchapuis and others added 6 commits December 12, 2022 22:52
…an included dependency

In [CALCITE-5399] we removed Proj4J as a dependency due to
licensing issues with the EPSG data set. In this change we
upgrade Proj4J to version 1.2.2, which no longer includes
the EPSG data set and therefore can be distributed under the
Apache license.

This change mostly consists of a reversal of [CALCITE-5399],
but also upgrades Proj4J.
Run Druid tests using JDK 17 to overcome DriverManager deadlock
affecting JDK 8.

Close apache#3004
…Query, and enabled in the BigQuery library)

The TIMESTAMP_DIFF function is implemented by
SqlLibraryOperators.TIMESTAMP_DIFF3 and only enabled with
lib=bigquery, whereas the built-in TIMESTAMPDIFF function is
implemented by SqlStdOperatorTable.TIMESTAMP_DIFF and is
always enabled.

Close apache#3000
Copy link

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 90 days if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the [email protected] list. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.