[jira] [Created] (CALCITE-6316) Update Javadoc for CALCITE-5607
Oliver Lee created CALCITE-6316: --- Summary: Update Javadoc for CALCITE-5607 Key: CALCITE-6316 URL: https://issues.apache.org/jira/browse/CALCITE-6316 Project: Calcite Issue Type: Task Reporter: Oliver Lee Assignee: Oliver Lee -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6301) Extend ‘Must-filter’ columns to support a conditional bypass list
Oliver Lee created CALCITE-6301: --- Summary: Extend ‘Must-filter’ columns to support a conditional bypass list Key: CALCITE-6301 URL: https://issues.apache.org/jira/browse/CALCITE-6301 Project: Calcite Issue Type: Improvement Reporter: Oliver Lee Assignee: Oliver Lee In [CALCITE-6219] we introduced SemanticTable, where tables that implement this interface can define fields to be ‘must-filter’, and a query without those filters in any of its WHERE or HAVING clauses, it will throw a validation error. I would like to extend this functionality to support a by-pass list of fields such that if any field from this secondary list is present in a WHERE / HAVING clause, then the must-filter fields can be ignored and will not raise an exception if not filtered on. Ex. EMP table specifies the following: Must-filter-fields: [EMPNO, DEPTNO] Bypass-fields: [ENAME] SELECT * FROM EMP WHERE EMPNO = 1 and DEPTNO = 2 -> No error SELECT * FROM EMP WHERE EMPNO = 1 -> Error SELECT * FROM EMP WHERE EMPNO = 1 and ENAME = ’name’ -> No error SELECT * FROM EMP WHERE ENAME = ’name’ -> No error Again, special considerations are for handling * Joins * CTEs * Subqueries And a similar exhaustive suite of tests like the one for [CALCITE-6219] should be employed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6219) Support SQL Validation for Tables with columns tagged as 'filter required'
Oliver Lee created CALCITE-6219:
---
Summary: Support SQL Validation for Tables with columns tagged as
'filter required'
Key: CALCITE-6219
URL: https://issues.apache.org/jira/browse/CALCITE-6219
Project: Calcite
Issue Type: New Feature
Reporter: Oliver Lee
Assignee: Oliver Lee
Suppose that a user's Table definitions come in with a tag on certain columns
that indicates the the column is required to have a filter on it for all
incoming queries.
I would like to add support to validate that incoming queries satisfies the
table condition.
If all of the table's specified fields has a filter on it (present in a WHERE
or HAVING clause for the query), then it will not error.
ex.
{{EMP}} table specifies that {{EMPNO}} requires a filter
{{select * from emp where empno = 1}} -> No error
{{select * from emp where ename = 'bob' -> Error}}
{{select * from emp -> Error}}
The validation would occur after the namespace validation in
{{SqlValidatorImpl}} as a separate pass.
I am envisioning that the full filter validation algorithm will form a couple
of key steps
* Scanning the catalog/schema/tables and determining which fields are tagged
to always require filters
* A pass through the SQL statement to see if a certain field needs to be
filtered multiple times (potentially for CTE, joins? needs further
investigation)
* A pass through the SQL statement to discover filters on the statement
In determining whether a {{WHERE}} or {{HAVING}} clause contains a certain
field identifier, there will need to be a helper visitor for WHERE or HAVING
SqlNodes to collect all of the SqlIdentifiers that could be nested within the
{{operandList}}
Special considerations:
* joins
* CTEs
* subqueries
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6039) PERCENTILE_CONT for BigQuery dialect has different syntax and is parsed incorrectly
Oliver Lee created CALCITE-6039:
---
Summary: PERCENTILE_CONT for BigQuery dialect has different syntax
and is parsed incorrectly
Key: CALCITE-6039
URL: https://issues.apache.org/jira/browse/CALCITE-6039
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
For Big Query syntax, PERCENTILE_CONT uses the key word OVER instead of WITHIN
GROUP
See documentation
[here|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#percentile_cont].
There are a couple of issues incorrect with current parsing
* {{Parser.jj}} currently will incorrectly parses OVER into
{{SqlOverOperator}} (which is correct for other dialects, however not entirely
correct for Big Query)
* Should support: OVER(PARTITION BY y ORDER BY x)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6036) Support WITHIN GROUP(ORDER BY x) OVER (PARTITION BY y)
Oliver Lee created CALCITE-6036:
---
Summary: Support WITHIN GROUP(ORDER BY x) OVER (PARTITION BY y)
Key: CALCITE-6036
URL: https://issues.apache.org/jira/browse/CALCITE-6036
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
[According to Oracle in ISO
SQL|https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/PERCENTILE_CONT.html#GUID-CA259452-A565-41B3-A4F4-DD74B66CEDE0],
in functions such as PERCENTILE_CONT or PERCENTILE_DISC, it should support the
clauses
{{WITHIN GROUP(ORDER BY x) OVER (PARTITION BY y)}}
Currently, when trying to run a {{{}RelToSqlConverterTest{}}}, a sample query:
{quote}SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY product_class_id)
OVER (PARTITION BY product_class_id) from food mart.product
{quote}
the validator will throw an error: {{OVER must be applied to aggregate
function}}
(PERCENTILE_CONT is not an aggregate function and any SqlOverOperator/RexOver
requires the operator to be an aggregate function))
Desired behavior:
The OVER clause should be able to be used in conjunction with the WITHIN GROUP
clause
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6035) Correctly unparse WITHIN GROUP for Big Query dialect
Oliver Lee created CALCITE-6035:
---
Summary: Correctly unparse WITHIN GROUP for Big Query dialect
Key: CALCITE-6035
URL: https://issues.apache.org/jira/browse/CALCITE-6035
Project: Calcite
Issue Type: Improvement
Reporter: Oliver Lee
Assignee: Oliver Lee
In Big Query SQL, the {{percentile_cont}}
[function|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#percentile_cont]
uses the keyword {{OVER}} instead of WITHIN GROUP.
This is not to be confused with ISO SQL OVER, which is used in windowed
aggregate functions. (percentile_cont is not a window function)
Requirements:
{{select percentile_cont(0.5) within group (order by x)}} in ISO SQL should be
unparsed as {{select percentile_cont(0.5) over (order by x)}} in Big Query SQL
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5982) Allow overloading the created enumerable in Calcite when calling getTables() or getColumns()
Oliver Lee created CALCITE-5982:
---
Summary: Allow overloading the created enumerable in Calcite when
calling getTables() or getColumns()
Key: CALCITE-5982
URL: https://issues.apache.org/jira/browse/CALCITE-5982
Project: Calcite
Issue Type: New Feature
Reporter: Oliver Lee
Assignee: Oliver Lee
The goal is to introduce a mechanism that allows overloading the enumerable
type that is created when {{getTables()}} and {{getColumns()}} is called. If a
user provides an overloaded {{{}MetaTable{}}}/ {{MetaColumn}} class, then they
can add in additional metadata fields that they would like to be transferred.
Currently, {{CalciteMetaImpl}} in {{getTables()}} and {{getColumns()}} calls
are hardcoded to do reflection on {{MetaTable.class}} and {{MetaColumn.class}}
‘ fields, matched with the list of column names that are passed in. Reflection
is important here, as it creates the proper {{ColumnMetaData}} and
{{Signature}} that the client needs to deserialize.
See here for {{[getTables()|#L270]]}} and here for
[{{getColumns()}}|https://github.com/apache/calcite/blob/164ff0a27e243850d294908dc5cff90760d0a35a/core/src/main/java/org/apache/calcite/jdbc/CalciteMetaImpl.java#L320]
I would like to introduce fields ( {{metaTableClass}} , {{metaColumnClass}} )
on {{CalciteMetaImpl}} that determine which class to use for each of these.
This will be configured as a {{CalciteConnectionProperty}} when making the
{{jdbc:calcite}} connection
Requirements:
* User can specify in {{Properties}} new {{CalciteConnectionProperty}} ’s to
specify which overloaded class of {{CalciteMetaTable}} and {{MetaColumn}} to use
* If not specified, it will default to {{CalciteMetaTable.class}} and
{{MetaColumn.class}}
The provided overloaded class will create a subclass of {{CalciteMetaTable}} /
{{MetaColumn}} that has the same shape constructor and also provide an override
for the function {{{}getColumnNames(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5964) Support additional metadata attributes in GET_TABLES and GET_COLUMNS
Oliver Lee created CALCITE-5964:
---
Summary: Support additional metadata attributes in GET_TABLES and
GET_COLUMNS
Key: CALCITE-5964
URL: https://issues.apache.org/jira/browse/CALCITE-5964
Project: Calcite
Issue Type: New Feature
Components: avatica
Reporter: Oliver Lee
Assignee: Oliver Lee
The goal is to add to the Avatica client a mechanism such that additional
metadata fields pertaining to tables and columns can be transmitted alongside
the standard JDBC
[\{{getTables}}|(https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A-)]
and {{getColumns}} calls.
The Avatica client needs the response to be extensible such that revisions to
metadata fields send and future additions does not require a new JAR file.
Requirements:
# Avatica user does not need to download new jar files if the server decides
to send over new metadata data in the future
# If the client makes modifications to support additional columns, they should
always be present in the call and appear with null values, as opposed to
complete omission (Number of columns in response stays the same)
# Can handle attributes of varying types i.e. {{numberOne: int}} and
{{booleanOne: boolean}}
# Allows value retrieval from the {{ResultSet}} through calling
{{resultSet.getInt(“booleanOne”)}} or {{resultSet.getBoolean(“booleanOne”)}}
Current proposal is to modify the {{MetaTable}} and {{MetaColumn}} classes to
include a map.
{{{}HashMap{}}}, such that when instantiating the
{{CalciteMetaTable}} in the {{{}ResultSet{}}}, new entries could be added in
the future without changes to Avatica.
One we have a list of additional metadata fields to be emitted in
{{{}CalciteMetaImpl{}}}, the {{ResultSet}} would be created with the
appropriate values.
There are still some challenges identified below and I would love some input:
Challenges:
* Currently the {{MetaTable}} class that is instantiated is a
{{{}CalciteMetaImpl{}}}. For the {{getTables()}} call, the response will be a
list composed of schema tables of class {{CalciteMetaTable}} and database
tables which can potentially be overloaded into 1 or more different subclasses.
From this one heterogeneous list, we must determine the full list of columns to
be included in the additional metadata hash. My initial plan was to provide a
function in Calcite’s {{Table}} class such as {{getAdditionalColumns}} and
allow it to be overloaded, but then I discovered the heterogeneity of the list.
* Modifying the MetaTable class to include the hashmap of values could be
easily done, but the challenge lies at {{{}RemoteMeta{}}}, to be able to
serialize this cleanly so that requirement (4) is met and users can retrieve
the values nicely. {{RemoteMeta}} currently serializes the response using
reflection by looking at MetaTable.class and its attributes. The addition of
one map is not immediately compatible with iterating over the keys of the map
and turning each of those into fields. I’m looking into the idea of processing
the enumerable in {{CalciteMetaImpl}} before the Frame gets created
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5755) Add to Sarg serialization/deserialization TimestampString
Oliver Lee created CALCITE-5755: --- Summary: Add to Sarg serialization/deserialization TimestampString Key: CALCITE-5755 URL: https://issues.apache.org/jira/browse/CALCITE-5755 Project: Calcite Issue Type: Sub-task Reporter: Oliver Lee Currently Sarg serialization/deserialization allows for 6 types [https://github.com/apache/calcite/blob/967bb5acc5448bc8d6ee9b9f5fa3c5f0d71405c2/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L113] and doesn't include `TimestampString` Currently, it will not throw an error, but will deserialize incorrectly as a `Date` set to the epoch beginning. Desired outcome: Be able to serialize / deserialize SEARCH operators that contain Timestamp string literals. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5694) RelJson fails to serialize/deserialize AggregateCall
Oliver Lee created CALCITE-5694:
---
Summary: RelJson fails to serialize/deserialize AggregateCall
Key: CALCITE-5694
URL: https://issues.apache.org/jira/browse/CALCITE-5694
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
Assignee: Oliver Lee
The current output of {{RelJson.toJson(AggregateCall call)}} will fail to
serialize back into an {{{}AggregateCall{}}}.
and throw {{java.lang.UnsupportedOperationException: cannot convert to rex}}
Correct behavior:
{quote}AggregateCall aggCall;
Object jsonRepresentation = relJson.toJson(aggCall);
assertThat(jsonRepresentation, notNullValue());
RexNode deserialized = relJson.toRex(b.getCluster(), jsonRepresentation);
assertThat(aggCall, is(deserialized));
assertThat(jsonRepresentation, is(relJson.toJson(deserialized)));
{quote}
These 2 assert statements should evaluate to {{{}true{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5662) Fix CAST(BOOLEAN as INTEGER)
Oliver Lee created CALCITE-5662:
---
Summary: Fix CAST(BOOLEAN as INTEGER)
Key: CALCITE-5662
URL: https://issues.apache.org/jira/browse/CALCITE-5662
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
Assignee: Oliver Lee
Currently attempting to run {{SELECT CAST(BOOLEAN as INTEGER)}} will throw a
{{NumberFormatException}}.
The BigQuery dialect allows casting {{boolean}} to {{int64}} and {{string}},
and not for decimal, bigdecimal, numeric, etc.
src:
https://cloud.google.com/bigquery/docs/reference/standard-sql/conversion_functions
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5659) Allow CAST in an INTERVAL definition
Oliver Lee created CALCITE-5659:
---
Summary: Allow CAST in an INTERVAL definition
Key: CALCITE-5659
URL: https://issues.apache.org/jira/browse/CALCITE-5659
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
Assignee: Oliver Lee
Running queries that contain a CAST as part of the INTERVAL definition is
throwing a parser error.
i.e.
{{INTERVAL CAST(5 as int64) YEAR}}
We can make parser changes to allow the Cast function tokens to be accepted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5625) Expand SEARCH RexNode when converting toJson
Oliver Lee created CALCITE-5625: --- Summary: Expand SEARCH RexNode when converting toJson Key: CALCITE-5625 URL: https://issues.apache.org/jira/browse/CALCITE-5625 Project: Calcite Issue Type: Sub-task Reporter: Oliver Lee Because the Sarg class is not able to be serialized/deserialized to/from JSON, we would like to expand the SEARCH RexNode as a workaround. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5614) Serialize and deserialize Sarg objects
Oliver Lee created CALCITE-5614:
---
Summary: Serialize and deserialize Sarg objects
Key: CALCITE-5614
URL: https://issues.apache.org/jira/browse/CALCITE-5614
Project: Calcite
Issue Type: Improvement
Reporter: Oliver Lee
Add functionality such that {{Sarg}} literals can be serialized and
deserialized.
{{RelJson.java}} should be updated so that {{toRex}} can serialize {{Sarg}}
objects
{{RexBuilder.java}} should be updated to be able to successfully deserialize a
JSON string that includes {{Sarg}} literals
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5607) Serialize return type during RelJson.toJson(RexNode node) serialization
Oliver Lee created CALCITE-5607:
---
Summary: Serialize return type during RelJson.toJson(RexNode node)
serialization
Key: CALCITE-5607
URL: https://issues.apache.org/jira/browse/CALCITE-5607
Project: Calcite
Issue Type: Improvement
Reporter: Oliver Lee
We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
Query dialect.
{{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
[operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
with a return type explicitly declared as the interval.
{{MINUS_DATE}} uses an
{{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
return type inference which requires 3 operands. This is fine in most cases
where the RexCall is then used to generate SQL or for native implementations.
However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire call
to a RexNode, it attempts to derive the return type of the {{MINUS_DATE}}
operator using the {{ARG2_NULLABLE}} inference. This throws an error as there
are only 2 operands given to the {{MINUS_DATE}} operator.
We'd like to now add in the "type" when serializing the JSON so that
{{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
will be defined in {{{}toRex{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5557) Add SAFE_CAST (big BigQuery compatibility)
Oliver Lee created CALCITE-5557:
---
Summary: Add SAFE_CAST (big BigQuery compatibility)
Key: CALCITE-5557
URL: https://issues.apache.org/jira/browse/CALCITE-5557
Project: Calcite
Issue Type: New Feature
Reporter: Oliver Lee
Implement SAFE_CAST per BigQuery specifications
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#safe_casting
Equivalent to CAST(), except it will return {{null}} instead of throwing an
exception if the casting fails.
SAFE_CAST("1" as INT64) -> 1
SAFE_CAST("a" as INT64) -> null
SAFE_CAST("2022-12-12" as DATE) -> DATE('2022-12-12')
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5545) Allow for overriding SqlValidator to enable custom SqlNode validation
Oliver Lee created CALCITE-5545:
---
Summary: Allow for overriding SqlValidator to enable custom
SqlNode validation
Key: CALCITE-5545
URL: https://issues.apache.org/jira/browse/CALCITE-5545
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
Goal: Be able to enable custom SqlNode validation
It will require overloading {{CalcitePrepareImpl}}, setting the
{{prepareFactory}} in {{Driver.java}} to use the overloaded
{{CalcitePrepareImpl}}, and then overloading {{createSqlValidator()}} and
{{getSqlValidator()}} of {{CalcitePreparingStmt}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5533) Unclear type name in FamilyOperandTypeChecker getAllowedSignature()
Oliver Lee created CALCITE-5533:
---
Summary: Unclear type name in FamilyOperandTypeChecker
getAllowedSignature()
Key: CALCITE-5533
URL: https://issues.apache.org/jira/browse/CALCITE-5533
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
The error message from in {{getAllowedSignature()}} for
{{FamilyOperandTypeChecker}} [uses the
SqlTypeFamily|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/FamilyOperandTypeChecker.java#L190]instead
of the actual type that is used/supplied.
For example this query using the Big Query dialect (BQ TIMESTAMP is Calcite's
TIMESTAMP_WITH_LOCAL_TIME_ZONE)
{quote}SELECT TIMESTAMP_DIFF(1, TIMESTAMP "2008-12-25 15:30:00", HOUR)
{quote}
You would expect the error message in the current state to be produced using
Calcite types:
{quote}Cannot apply 'TIMESTAMP_DIFF' to arguments of type
'TIMESTAMP_DIFF(, , )'. Supported form(s): 'TIMESTAMP_DIFF(,
, )'
{quote}
However the error message is actually:
{quote}Cannot apply 'TIMESTAMP_DIFF' to arguments of type
'TIMESTAMP_DIFF(, , )'. Supported form(s): 'TIMESTAMP_DIFF(, , )'
{quote}
The
[TIMESTAMP_DIFF|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L811]
function checks that the operands are from the
[SqlTypeFamily.TIMESTAMP|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/SqlTypeFamily.java#L182]
type family and the error message [uses the family
name|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/FamilyOperandTypeChecker.java#L190]
SqlTypeFamily.TIMESTAMP, not the SqlTypeName
[SqlTypeName.TIMESTAMP_WITH_LOCAL_TIME_ZONE|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/SqlTypeFamily.java#L183].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5499) BigQuery TIMESTAMP_TRUNC() not fully implemented
Oliver Lee created CALCITE-5499:
---
Summary: BigQuery TIMESTAMP_TRUNC() not fully implemented
Key: CALCITE-5499
URL: https://issues.apache.org/jira/browse/CALCITE-5499
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
BigQuery documentation shows that TIMESTAMP_TRUNC supports an optional 3rd
argument, time zone
Docs:
[https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp_trunc]
The current implementation does not support that.
{{SELECT
timestamp_value AS timestamp_value,
TIMESTAMP_TRUNC(timestamp_value, WEEK(MONDAY), "UTC") AS utc_truncated,
TIMESTAMP_TRUNC(timestamp_value, WEEK(MONDAY), "Pacific/Auckland") AS
nzdt_truncated
FROM (SELECT TIMESTAMP("2017-11-06 00:00:00+12") AS timestamp_value);
-- Display of results may differ, depending upon the environment and time zone
where this query was executed.
+-+-+-+
| timestamp_value | utc_truncated | nzdt_truncated |
+-+-+-+
| 2017-11-05 12:00:00 UTC | 2017-10-30 00:00:00 UTC | 2017-11-05 11:00:00 UTC |
+-+-+-+}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5498) BigQuery TIMESTAMP() function short notation for timezone offsets isn’t supported in Java 8
Oliver Lee created CALCITE-5498:
---
Summary: BigQuery TIMESTAMP() function short notation for timezone
offsets isn’t supported in Java 8
Key: CALCITE-5498
URL: https://issues.apache.org/jira/browse/CALCITE-5498
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
DateTimeFormatter had this issue in Java 8, fixed in Java 9 and beyond.
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8210336
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8032051
{{2013-12-11T21:25:04.800842+01:00}} is supported
{{2013-12-11T21:25:04.800842+01}} is not supported
Sounds low priority but we should investigate how to have consistent behavior
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5496) Support time zones when parsing TIMESTAMP literals
Oliver Lee created CALCITE-5496:
---
Summary: Support time zones when parsing TIMESTAMP literals
Key: CALCITE-5496
URL: https://issues.apache.org/jira/browse/CALCITE-5496
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
In Avatica, DateTimeUtils TIMESTAMP_FORMAT_STRING is {{DATE_FORMAT_STRING + " "
+ TIME_FORMAT_STRING}} which is {{"HH:mm:ss"}} with no handling for time zones
if specified.
i.e. in Calcite quidem tests if we run
{\{DATETIME(TIMESTAMP "2008-12-25 05:30:00+00", "America/Los_Angeles") as
datetime_tstz}}
the TIMESTAMP literal is not supported
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5497) Support time zones when parsing TIMESTAMP literals
Oliver Lee created CALCITE-5497:
---
Summary: Support time zones when parsing TIMESTAMP literals
Key: CALCITE-5497
URL: https://issues.apache.org/jira/browse/CALCITE-5497
Project: Calcite
Issue Type: Bug
Reporter: Oliver Lee
In Avatica, DateTimeUtils TIMESTAMP_FORMAT_STRING is {{DATE_FORMAT_STRING + " "
+ TIME_FORMAT_STRING}} which is {{"HH:mm:ss"}} with no handling for time zones
if specified.
i.e. in Calcite quidem tests if we run
{\{DATETIME(TIMESTAMP "2008-12-25 05:30:00+00", "America/Los_Angeles") as
datetime_tstz}}
the TIMESTAMP literal is not supported
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5476) Add DATETIME_TRUNC for BigQuery
Oliver Lee created CALCITE-5476:
---
Summary: Add DATETIME_TRUNC for BigQuery
Key: CALCITE-5476
URL: https://issues.apache.org/jira/browse/CALCITE-5476
Project: Calcite
Issue Type: Improvement
Reporter: Oliver Lee
Assignee: Oliver Lee
Adding in DATETIME_TRUNC() to the BigQuery library as described here:
[https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#datetime_trunc]
Truncates a {{DATETIME}} value to the granularity of {{{}date_time_part{}}}.
The {{DATETIME}} value is always rounded to the beginning of
{{{}date_time_part{}}}, which can be one of the following:
* {{{}MICROSECOND{}}}: If used, nothing is truncated from the value.
* {{{}MILLISECOND{}}}: The nearest lessor or equal millisecond.
* {{{}SECOND{}}}: The nearest lessor or equal second.
* {{{}MINUTE{}}}: The nearest lessor or equal minute.
* {{{}HOUR{}}}: The nearest lessor or equal hour.
* {{{}DAY{}}}: The day in the Gregorian calendar year that contains the
{{DATETIME}} value.
* {{{}WEEK{}}}: The first day of the week in the week that contains the
{{DATETIME}} value. Weeks begin on Sundays. {{WEEK}} is equivalent to
{{{}WEEK(SUNDAY){}}}.
* {{{}WEEK(WEEKDAY){}}}: The first day of the week in the week that contains
the {{DATETIME}} value. Weeks begin on {{{}WEEKDAY{}}}. {{WEEKDAY}} must be one
of the following: {{{}SUNDAY{}}}, {{{}MONDAY{}}}, {{{}TUESDAY{}}},
{{{}WEDNESDAY{}}}, {{{}THURSDAY{}}}, {{{}FRIDAY{}}}, or {{{}SATURDAY{}}}.
* {{{}ISOWEEK{}}}: The first day of the [ISO 8601
week|https://en.wikipedia.org/wiki/ISO_week_date] in the ISO week that contains
the {{DATETIME}} value. The ISO week begins on Monday. The first ISO week of
each ISO year contains the first Thursday of the corresponding Gregorian
calendar year.
* {{{}MONTH{}}}: The first day of the month in the month that contains the
{{DATETIME}} value.
* {{{}QUARTER{}}}: The first day of the quarter in the quarter that contains
the {{DATETIME}} value.
* {{{}YEAR{}}}: The first day of the year in the year that contains the
{{DATETIME}} value.
* {{{}ISOYEAR{}}}: The first day of the [ISO
8601|https://en.wikipedia.org/wiki/ISO_8601] week-numbering year in the ISO
year that contains the {{DATETIME}} value. The ISO year is the Monday of the
first week whose Thursday belongs to the corresponding Gregorian calendar year.
{{SELECT DATETIME_TRUNC(DATETIME "2008-12-25 15:30:00", DAY) ->
2008-12-25T00:00:00}}
{{}}
{{}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5455) Add NULLIF() for BIG_QUERY
Oliver Lee created CALCITE-5455: --- Summary: Add NULLIF() for BIG_QUERY Key: CALCITE-5455 URL: https://issues.apache.org/jira/browse/CALCITE-5455 Project: Calcite Issue Type: Improvement Reporter: Oliver Lee -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5451) Add LPAD() for BIG_QUERY
Oliver Lee created CALCITE-5451: --- Summary: Add LPAD() for BIG_QUERY Key: CALCITE-5451 URL: https://issues.apache.org/jira/browse/CALCITE-5451 Project: Calcite Issue Type: Improvement Reporter: Oliver Lee Assignee: Oliver Lee Adding in LPAD() for BIG_QUERY as per [https://g3doc.corp.google.com/company/teams/googlesql/reference/string_functions.md?cl=head#lpad] describes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5450) Add to parser WEEK(WEEKDAY) for custom time frames
Oliver Lee created CALCITE-5450:
---
Summary: Add to parser WEEK(WEEKDAY) for custom time frames
Key: CALCITE-5450
URL: https://issues.apache.org/jira/browse/CALCITE-5450
Project: Calcite
Issue Type: Improvement
Reporter: Oliver Lee
Some BIG_QUERY functions (i.e. {{{}EXTRACT(){}}}, {{DATE_TRUNC()}} ) can accept
the operand
{{WEEK(WEEKDAY)}} where {{WEEKDAY}} is one of {{SUNDAY, MONDAY, TUESDAY,
WEDNESDAY, THURSDAY, FRIDAY, SATURDAY}}
This is not currently supported.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5447) Add DATE_TRUNC for BigQuery
Oliver Lee created CALCITE-5447:
---
Summary: Add DATE_TRUNC for BigQuery
Key: CALCITE-5447
URL: https://issues.apache.org/jira/browse/CALCITE-5447
Project: Calcite
Issue Type: Improvement
Reporter: Oliver Lee
Adding in BigQuery's definition of DATE_TRUNC as described
[https://g3doc.corp.google.com/company/teams/googlesql/reference/date_functions.md?cl=head#date-trunc]
ex.
DATE_TRUNC('2022-01-05', month) -> 2022-01-01
DATE_TRUNC('2022-01-05', day) -> 2022-01-05
DATE_TRUNC('2022-01-05', year) -> 2022-01-01
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5430) Implement IFNULL() for BigQuery dialect
Oliver Lee created CALCITE-5430: --- Summary: Implement IFNULL() for BigQuery dialect Key: CALCITE-5430 URL: https://issues.apache.org/jira/browse/CALCITE-5430 Project: Calcite Issue Type: Improvement Reporter: Oliver Lee Assignee: Oliver Lee Implementing IFNULL() for BIG_QUERY dialect -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5389) STARTS_WITH for BIG_QUERY
Oliver Lee created CALCITE-5389: --- Summary: STARTS_WITH for BIG_QUERY Key: CALCITE-5389 URL: https://issues.apache.org/jira/browse/CALCITE-5389 Project: Calcite Issue Type: Improvement Reporter: Oliver Lee Adding support for STARTS_WITH for BIG_QUERY dialect -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5383) Update CONCAT function to allow BIG_QUERY
Oliver Lee created CALCITE-5383: --- Summary: Update CONCAT function to allow BIG_QUERY Key: CALCITE-5383 URL: https://issues.apache.org/jira/browse/CALCITE-5383 Project: Calcite Issue Type: Improvement Reporter: Oliver Lee Updating the string CONCAT function to allow BIG_QUERY in the SQL Libraries -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5358) Adding in HTTP_BAD_REQUEST error response
Oliver Lee created CALCITE-5358: --- Summary: Adding in HTTP_BAD_REQUEST error response Key: CALCITE-5358 URL: https://issues.apache.org/jira/browse/CALCITE-5358 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Oliver Lee The `createErrorResponse` function in `AstractHandler.java` [here|https://github.com/apache/calcite-avatica/blob/1f0f0c1c56b35c4524564a126f1db525437a130b/core/src/main/java/org/apache/calcite/avatica/remote/AbstractHandler.java#L126] doesn't include HTTP_BAD_REQUEST -- This message was sent by Atlassian Jira (v8.20.10#820010)
