[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)