[jira] [Created] (CALCITE-3468) Oracle cast to varchar does not use precision when it should
Lindsey Meyer created CALCITE-3468:
--
Summary: Oracle cast to varchar does not use precision when it
should
Key: CALCITE-3468
URL: https://issues.apache.org/jira/browse/CALCITE-3468
Project: Calcite
Issue Type: Improvement
Reporter: Lindsey Meyer
We're trying to cast a node to a varchar with something like this:
{noformat}
relBuilder.cast(node, SqlTypeName.VARCHAR)
{noformat}
And in Oracle SQL, this generates sql like
{noformat}
CAST(node AS VARCHAR){noformat}
which is incorrect. Oracle can only have VARCHAR types with an explicit
precision.
Looking at the code, it _seems_ like this should work with Oracle, so I'm not
really sure what's going on here
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3377) HSQLDB is case insensitive
[ https://issues.apache.org/jira/browse/CALCITE-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lindsey Meyer updated CALCITE-3377: --- Description: We just need to add to the HsqldbSqlDialect that it is case insensitive. This is necessary so the validator doesn't error on case mismatches for unquoted identifiers. cc [~jhyde] was: We just need to add to the HsqldbSqlDialect that it is case insensitive cc [~jhyde] > HSQLDB is case insensitive > -- > > Key: CALCITE-3377 > URL: https://issues.apache.org/jira/browse/CALCITE-3377 > Project: Calcite > Issue Type: Improvement >Reporter: Lindsey Meyer >Priority: Major > > We just need to add to the HsqldbSqlDialect that it is case insensitive. This > is necessary so the validator doesn't error on case mismatches for unquoted > identifiers. > cc [~jhyde] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3377) HSQLDB is case insensitive
Lindsey Meyer created CALCITE-3377: -- Summary: HSQLDB is case insensitive Key: CALCITE-3377 URL: https://issues.apache.org/jira/browse/CALCITE-3377 Project: Calcite Issue Type: Improvement Reporter: Lindsey Meyer We just need to add to the HsqldbSqlDialect that it is case insensitive cc [~jhyde] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3365) Don't require use of JdbcSchema in QuerySqlStatisticProvider
[ https://issues.apache.org/jira/browse/CALCITE-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937068#comment-16937068 ] Lindsey Meyer commented on CALCITE-3365: Looks good to me, thank you [~julianhyde]!! > Don't require use of JdbcSchema in QuerySqlStatisticProvider > > > Key: CALCITE-3365 > URL: https://issues.apache.org/jira/browse/CALCITE-3365 > Project: Calcite > Issue Type: Improvement >Reporter: Lindsey Meyer >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We're trying to pass in schema data manually to process queries for BigQuery, > but that causes problems in the QuerySqlStatisticProvider because it requires > a JdbcSchema in order to get the dialect and dataSource, as well as using a > Jdbc Builder. > I propose refactoring QuerySqlStatisticProvider to grab the dialect and > dataSource using unwrap on the schema instead, so that any schema that > implements unwrap methods for these types will work with > QuerySqlStatisticProvider. As well as using a generic RelBuilder, instead of > a JDBC_BUILDER. > cc [~julianhyde] since we have been discussing this > I've opened a PR at https://github.com/apache/calcite/pull/1467 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3365) Don't require use of JdbcSchema in QuerySqlStatisticProvider
Lindsey Meyer created CALCITE-3365: -- Summary: Don't require use of JdbcSchema in QuerySqlStatisticProvider Key: CALCITE-3365 URL: https://issues.apache.org/jira/browse/CALCITE-3365 Project: Calcite Issue Type: Improvement Reporter: Lindsey Meyer We're trying to pass in schema data manually to process queries for BigQuery, but that causes problems in the QuerySqlStatisticProvider because it requires a JdbcSchema in order to get the dialect and dataSource, as well as using a Jdbc Builder. I propose refactoring QuerySqlStatisticProvider to grab the dialect and dataSource using unwrap on the schema instead, so that any schema that implements unwrap methods for these types will work with QuerySqlStatisticProvider. As well as using a generic RelBuilder, instead of a JDBC_BUILDER. cc [~julianhyde] since we have been discussing this I've opened a PR at https://github.com/apache/calcite/pull/1467 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3321) Bigquery does not have correct casing rules
Lindsey Meyer created CALCITE-3321: -- Summary: Bigquery does not have correct casing rules Key: CALCITE-3321 URL: https://issues.apache.org/jira/browse/CALCITE-3321 Project: Calcite Issue Type: Bug Reporter: Lindsey Meyer Bigquery has some strange case sensitivity rules, so I think it should leave casing unchanged and make it not case sensitive See rules here: https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical#case_sensitivity -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3252) Syntax error while parsing CONVERT_TIMEZONE, TO_DATE, TO_TIMESTAMP functions on Redshift
[
https://issues.apache.org/jira/browse/CALCITE-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907516#comment-16907516
]
Lindsey Meyer commented on CALCITE-3252:
I am working on a PR for this!
> Syntax error while parsing CONVERT_TIMEZONE, TO_DATE, TO_TIMESTAMP functions
> on Redshift
>
>
> Key: CALCITE-3252
> URL: https://issues.apache.org/jira/browse/CALCITE-3252
> Project: Calcite
> Issue Type: Bug
>Reporter: Lindsey Meyer
>Priority: Major
>
> Example queries that error for these functions:
> {code:java}
> SELECT CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', CAST('2019-01-01
> 01:00:00' AS TIMESTAMP) FROM mytable {code}
> {code:java}
> SELECT TO_DATE('2019-01-01', '-MM-DD') FROM mytable {code}
> {code:java}
> SELECT TO_TIMESTAMP('2019-01-01 01:00:00', '-MM-DD HH:MM:SS') FROM
> mytable
> {code}
> With errors like:
> {code:java}
> No match found for function signature CONVERT_TIMEZONE(,
> , )
> {code}
> These are valid in Redshift and Postgres, except for CONVERT_TIMEZONE, which
> I believe is only valid on Redshift.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3252) Syntax error while parsing CONVERT_TIMEZONE, TO_DATE, TO_TIMESTAMP functions on Redshift
[
https://issues.apache.org/jira/browse/CALCITE-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lindsey Meyer updated CALCITE-3252:
---
Description:
Example queries that error for these functions:
{code:java}
SELECT CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', CAST('2019-01-01
01:00:00' AS TIMESTAMP) FROM mytable {code}
{code:java}
SELECT TO_DATE('2019-01-01', '-MM-DD') FROM mytable {code}
{code:java}
SELECT TO_TIMESTAMP('2019-01-01 01:00:00', '-MM-DD HH:MM:SS') FROM mytable
{code}
With errors like:
{code:java}
No match found for function signature CONVERT_TIMEZONE(,
, )
{code}
These are valid in Redshift and Postgres, except for CONVERT_TIMEZONE, which I
believe is only valid on Redshift.
was:
Example queries that error for these functions:
{code:java}
SELECT CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', CAST('2019-01-01
01:00:00' AS TIMESTAMP) FROM mytable {code}
{code:java}
SELECT TO_DATE('2019-01-01', '-MM-DD') FROM mytable {code}
{code:java}
SELECT TO_TIMESTAMP('2019-01-01 01:00:00', '-MM-DD HH:MM:SS') FROM mytable
{code}
With errors like:
{code:java}
No match found for function signature CONVERT_TIMEZONE(,
, )
{code}
These are valid in Redshift and Postgres, except for `CONVERT_TIMEZONE`, which
I believe is only valid on Redshift.
> Syntax error while parsing CONVERT_TIMEZONE, TO_DATE, TO_TIMESTAMP functions
> on Redshift
>
>
> Key: CALCITE-3252
> URL: https://issues.apache.org/jira/browse/CALCITE-3252
> Project: Calcite
> Issue Type: Bug
>Reporter: Lindsey Meyer
>Priority: Major
>
> Example queries that error for these functions:
> {code:java}
> SELECT CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', CAST('2019-01-01
> 01:00:00' AS TIMESTAMP) FROM mytable {code}
> {code:java}
> SELECT TO_DATE('2019-01-01', '-MM-DD') FROM mytable {code}
> {code:java}
> SELECT TO_TIMESTAMP('2019-01-01 01:00:00', '-MM-DD HH:MM:SS') FROM
> mytable
> {code}
> With errors like:
> {code:java}
> No match found for function signature CONVERT_TIMEZONE(,
> , )
> {code}
> These are valid in Redshift and Postgres, except for CONVERT_TIMEZONE, which
> I believe is only valid on Redshift.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3252) Syntax error while parsing CONVERT_TIMEZONE, TO_DATE, TO_TIMESTAMP functions on Redshift
Lindsey Meyer created CALCITE-3252:
--
Summary: Syntax error while parsing CONVERT_TIMEZONE, TO_DATE,
TO_TIMESTAMP functions on Redshift
Key: CALCITE-3252
URL: https://issues.apache.org/jira/browse/CALCITE-3252
Project: Calcite
Issue Type: Bug
Reporter: Lindsey Meyer
Example queries that error for these functions:
{code:java}
SELECT CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', CAST('2019-01-01
01:00:00' AS TIMESTAMP) FROM mytable {code}
{code:java}
SELECT TO_DATE('2019-01-01', '-MM-DD') FROM mytable {code}
{code:java}
SELECT TO_TIMESTAMP('2019-01-01 01:00:00', '-MM-DD HH:MM:SS') FROM mytable
{code}
With errors like:
{code:java}
No match found for function signature CONVERT_TIMEZONE(,
, )
{code}
These are valid in Redshift and Postgres, except for `CONVERT_TIMEZONE`, which
I believe is only valid on Redshift.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3218) Syntax error while parsing DATEADD
Lindsey Meyer created CALCITE-3218:
--
Summary: Syntax error while parsing DATEADD
Key: CALCITE-3218
URL: https://issues.apache.org/jira/browse/CALCITE-3218
Project: Calcite
Issue Type: Bug
Reporter: Lindsey Meyer
Syntax error while parsing DATEADD
{code:java}
SELECT
DATE(CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', events.event_date
)) AS "events.event_date",
COALESCE(SUM(events.daily_user_count ), 0) AS
"events.daily_active_users",
COALESCE(SUM(events.monthly_user_count ), 0) AS
"events.monthly_active_users"
FROM public.events_proto AS events
WHERE
(((events.event_date ) >= ((CONVERT_TIMEZONE('America/Los_Angeles',
'UTC', DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
'America/Los_Angeles', GETDATE())) AND (events.event_date ) <
((CONVERT_TIMEZONE('America/Los_Angeles', 'UTC', DATEADD(day,365,
DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
'America/Los_Angeles', GETDATE())) ) ))
GROUP BY 1
HAVING
NOT (COALESCE(SUM(events.monthly_user_count ), 0) = 0)
ORDER BY 1 DESC
LIMIT 500{code}
{code:java}
`Column 'year' not found in any table`
`DATEADD(year,1,...`
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
