[jira] [Created] (CALCITE-6365) Support for RETURNING clause of JSON_QUERY
Dawid Wysakowicz created CALCITE-6365:
-
Summary: Support for RETURNING clause of JSON_QUERY
Key: CALCITE-6365
URL: https://issues.apache.org/jira/browse/CALCITE-6365
Project: Calcite
Issue Type: New Feature
Reporter: Dawid Wysakowicz
SQL standard says {{JSON_QUERY}} should support {{RETURNING}} clause similar to
{{JSON_VALUE}}. Calcite supports the clause for JSON_VALUE already, but not for
the JSON_QUERY.
{code}
::=
JSON_QUERY
[ ]
[ WRAPPER ]
[ QUOTES [ ON SCALAR STRING ] ]
[ ON EMPTY ]
[ ON ERROR ]
::=
RETURNING
[ FORMAT ]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6342) Use highest input precision for datetime with/without local time zone
Dawid Wysakowicz created CALCITE-6342:
-
Summary: Use highest input precision for datetime with/without
local time zone
Key: CALCITE-6342
URL: https://issues.apache.org/jira/browse/CALCITE-6342
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Dawid Wysakowicz
In [CALCITE-5478] it was correctly improved that the precision should be taken
into account when calculating {{leastRestrictive}} type of {{Datetime}} types.
Unfortunately it still does not behave well for a call like:
{{leastRestrictive(TIMESTAMP_LTZ(0), TIMESTAMP(3)}}. It produces
{{TIMESTAMP_LTZ(0)}}.
In my opinion this should produce at least {{TIMESTAMP(3)}}.
I'd suggest modifying the code a little bit to:
{code}
if (type.getSqlTypeName().getFamily() ==
resultType.getSqlTypeName().getFamily()
&& type.getSqlTypeName().allowsPrec()
&& type.getPrecision() != resultType.getPrecision()) {
final int precision =
SqlTypeUtil.maxPrecision(resultType.getPrecision(),
type.getPrecision());
resultType = createSqlType(type.getSqlTypeName(),
precision);
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-4390) SqlMatchRecognize returns wrong operand list
Dawid Wysakowicz created CALCITE-4390:
-
Summary: SqlMatchRecognize returns wrong operand list
Key: CALCITE-4390
URL: https://issues.apache.org/jira/browse/CALCITE-4390
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
The {{SqlMatchRecognize}} does not return full list of its operands. The method
{{SqlMatchRecognizeOperator#createCall}} expects 12 operands whereas
{{SqlMatchRecognize#getOperandList}} returns only 10. It misses
{{rowsPerMatch}} and {{interval}}.
It results that the {{SqlShuttle}} and more concretely the
{{CallCopyingArgHandler}} does not work with {{SqlMatchRecognize}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-2747) No exception when ambigous column reference defined in PARTITION BY and MEASURES clause
Dawid Wysakowicz created CALCITE-2747:
-
Summary: No exception when ambigous column reference defined in
PARTITION BY and MEASURES clause
Key: CALCITE-2747
URL: https://issues.apache.org/jira/browse/CALCITE-2747
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
Assignee: Julian Hyde
Query:
{code}
SELECT *
FROM MyTable
MATCH_RECOGNIZE (
PARTITION BY id
ORDER BY proctime
MEASURES
A.id AS id
PATTERN (A)
DEFINE
A AS name = 'a'
) AS T
{code}
should fail because of ambiguous {{id}} column.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2746) Cryptic exception when expression used in PARTITION BY clause in MATCH_RECOGNIZE
Dawid Wysakowicz created CALCITE-2746:
-
Summary: Cryptic exception when expression used in PARTITION BY
clause in MATCH_RECOGNIZE
Key: CALCITE-2746
URL: https://issues.apache.org/jira/browse/CALCITE-2746
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
Assignee: Julian Hyde
Query:
{code}
SELECT *
FROM MyTable
MATCH_RECOGNIZE (
PARTITION BY (id + 2)
ORDER BY proctime
MEASURES
A.id AS id
PATTERN (A)
DEFINE
A AS name = 'a'
) AS T
{code}
results in exception:
{code}
Caused by: java.lang.ClassCastException: org.apache.calcite.sql.SqlBasicCall
cannot be cast to org.apache.calcite.sql.SqlIdentifier
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateMatchRecognize(SqlValidatorImpl.java:4885)
at
org.apache.calcite.sql.validate.MatchRecognizeNamespace.validateImpl(MatchRecognizeNamespace.java:38)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:972)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:948)
{code}
I suggest improving it to give a proper hint that only input reference is
supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2708) UDAGs are not verified for single pattern variable in MATCH_RECOGNIZE
Dawid Wysakowicz created CALCITE-2708:
-
Summary: UDAGs are not verified for single pattern variable in
MATCH_RECOGNIZE
Key: CALCITE-2708
URL: https://issues.apache.org/jira/browse/CALCITE-2708
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
Assignee: Julian Hyde
Query:
{code}
SELECT *
FROM Ticker
MATCH_RECOGNIZE (
ORDER BY proctime
MEASURES
udagg(A.price + B.tax) AS taxedPrice
PATTERN (A B)
DEFINE
A AS A.symbol = 'a'
) AS T
{code}
should fail with ValidationException, because udagg is applied to different
pattern variables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2707) Information about distinct aggregation is lost in MATCH_RECOGNIZE
Dawid Wysakowicz created CALCITE-2707:
-
Summary: Information about distinct aggregation is lost in
MATCH_RECOGNIZE
Key: CALCITE-2707
URL: https://issues.apache.org/jira/browse/CALCITE-2707
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
Assignee: Julian Hyde
There is no information that the COUNT aggregation is distinct in a plan for a
query like e.g. this:
{code}
SELECT *
FROM MyTable
MATCH_RECOGNIZE (
MEASURES
AFTER MATCH SKIP PAST LAST ROW
PATTERN (A B+ C)
DEFINE
B AS COUNT(DISTINCT B.id) < 4
) AS T
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2664) Change default option for AFTER MATCH SKIP to SQL standard compliant one
Dawid Wysakowicz created CALCITE-2664:
-
Summary: Change default option for AFTER MATCH SKIP to SQL
standard compliant one
Key: CALCITE-2664
URL: https://issues.apache.org/jira/browse/CALCITE-2664
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
Assignee: Julian Hyde
Right now the default option is {{SKIP TO NEXT ROW}}, but the SQL standard says
the default one should be {{SKIP PAST LAST ROW}}. I suggest to change the
default to be SQL standard compliant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
