[jira] [Updated] (CALCITE-1918) Add support for Regular Expression Operators (RLIKE)
[
https://issues.apache.org/jira/browse/CALCITE-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sunjincheng updated CALCITE-1918:
-
Description:
Currently Regular Expression Operators (RLIKE) are not supported. e.g.:
{code}
select * from emps name rlike '^(K|G|W)'
{code}
we'll get Error:
{code}
Error: Error while executing SQL "select * from emps name rlike '^(K|G|W)'":
parse failed: Encountered "rlike" at line 1, column 25.
{code}
So, in this JIRA. I want add RLIKE supported.
Reference:
MySql: https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp
was:
Currently Regular Expression Operators (RLIKE) are not supported. e.g.:
{code}
select * from emps name rlike '^(K|G|W)'
{code}
we'll get Error:
{code}
Error: Error while executing SQL "select * from emps name rlike '^(K|G|W)'":
parse failed: Encountered "rlike" at line 1, column 25.
{code}
So, in this JIRA. I want add RLIKE supported.
> Add support for Regular Expression Operators (RLIKE)
> -
>
> Key: CALCITE-1918
> URL: https://issues.apache.org/jira/browse/CALCITE-1918
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: sunjincheng
>Assignee: sunjincheng
>
> Currently Regular Expression Operators (RLIKE) are not supported. e.g.:
> {code}
> select * from emps name rlike '^(K|G|W)'
> {code}
> we'll get Error:
> {code}
> Error: Error while executing SQL "select * from emps name rlike '^(K|G|W)'":
> parse failed: Encountered "rlike" at line 1, column 25.
> {code}
> So, in this JIRA. I want add RLIKE supported.
> Reference:
> MySql: https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1915) Workaround Jetty SpnegoAuthenticator bug where no challenge is sent
[ https://issues.apache.org/jira/browse/CALCITE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110172#comment-16110172 ] Josh Elser commented on CALCITE-1915: - AIUI, this will land in the next Jetty-9.4 release. As such, until we change from Jetty-9.2 to 9.4, we'll have to have a workaround. The change is easy, but writing a test will take a little bit of time. I'll try to do this tmrw so it doesn't wane. > Workaround Jetty SpnegoAuthenticator bug where no challenge is sent > --- > > Key: CALCITE-1915 > URL: https://issues.apache.org/jira/browse/CALCITE-1915 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.11.0 > > > I stumbled across what I think is a bug in Jetty per the RFC-7616. The RFC > reads (to me) as the following: > When a client sends an authorization header that is not capable of being used > to authenticate via SPNEGO, the server should send back the > WWW-Authentication: Negotiate HTTP header with a status code of HTTP/401. > Jetty will only send this challenge+401 when *no* Authorization header is > provided. > In the case where Avatica is sitting behind a reverse-proxy, the proxy _may_ > choose to pass along another authorization header. Jetty (and Avatica) should > still respond to say "You need to authenticate over SPNEGO". > At least Jetty dev seems to agree with my assessment: > https://github.com/eclipse/jetty.project/issues/1698. We can easily work > around this in Avatica while we wait to get a Jetty release which has this > fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
[
https://issues.apache.org/jira/browse/CALCITE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110168#comment-16110168
]
Jark Wu commented on CALCITE-1917:
--
Hi [~julianhyde] , I expect that we can continue the discussion about joining
temporal tables (i.e. whether to support column reference) under this JIRA :)
> Support column reference in "FOR SYSTEM_TIME AS OF"
> ---
>
> Key: CALCITE-1917
> URL: https://issues.apache.org/jira/browse/CALCITE-1917
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailing list[1], the standard says QSTPS can’t contain a
> column reference. So when joining the Orders to the Products table for the
> price as of the time the order was placed is impossible using "FOR
> SYSTEM_TIME AS OF". But can be expressed using a subquery, such as:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime
> AND sysEnd > O.orderTime) AS P
> ON o.productId = p.productId
> {code}
> But subquery is too complex for users. We know that the standard says it
> can’t contain a column reference. We initialize this discuss as we would like
> to "extend" the standard to simplify such query:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL ProductPrices FOR SYSTEM_TIME AS OF O.orderTime AS P
> ON o.productId = p.productId
> {code}
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
[
https://issues.apache.org/jira/browse/CALCITE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-1917:
-
Description:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL ProductPrices FOR SYSTEM_TIME AS OF O.orderTime AS P
ON o.productId = p.productId
{code}
[1]
https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
was:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
[1]
https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
> Support column reference in "FOR SYSTEM_TIME AS OF"
> ---
>
> Key: CALCITE-1917
> URL: https://issues.apache.org/jira/browse/CALCITE-1917
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailing list[1], the standard says QSTPS can’t contain a
> column reference. So when joining the Orders to the Products table for the
> price as of the time the order was placed is impossible using "FOR
> SYSTEM_TIME AS OF". But can be expressed using a subquery, such as:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime
> AND sysEnd > O.orderTime) AS P
> ON o.productId = p.productId
> {code}
> But subquery is too complex for users. We know that the standard says it
> can’t contain a column reference. We initialize this discuss as we would like
> to "extend" the standard to simplify such query:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL ProductPrices FOR SYSTEM_TIME AS OF O.orderTime AS P
> ON o.productId = p.productId
> {code}
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
[
https://issues.apache.org/jira/browse/CALCITE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-1917:
-
Description:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
[1]
https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
was:
you mean it can be covered by standard. I agree, the query I posted in the
previous mail can be rewrote as a subquery:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
> Support column reference in "FOR SYSTEM_TIME AS OF"
> ---
>
> Key: CALCITE-1917
> URL: https://issues.apache.org/jira/browse/CALCITE-1917
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailing list[1], the standard says QSTPS can’t contain a
> column reference. So when joining the Orders to the Products table for the
> price as of the time the order was placed is impossible using "FOR
> SYSTEM_TIME AS OF". But can be expressed using a subquery, such as:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime
> AND sysEnd > O.orderTime) AS P
> ON o.productId = p.productId
> {code}
> But subquery is too complex for users. We know that the standard says it
> can’t contain a column reference. We initialize this discuss as we would like
> to "extend" the standard to simplify such query.
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
Jark Wu created CALCITE-1917:
Summary: Support column reference in "FOR SYSTEM_TIME AS OF"
Key: CALCITE-1917
URL: https://issues.apache.org/jira/browse/CALCITE-1917
Project: Calcite
Issue Type: New Feature
Reporter: Jark Wu
Assignee: Julian Hyde
you mean it can be covered by standard. I agree, the query I posted in the
previous mail can be rewrote as a subquery:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110005#comment-16110005 ] Francis Chuang commented on CALCITE-1240: - [~julianhyde] Thanks for organizing this! An empty repo is fine, I can push the existing code into the repo. Should I push the existing tags or should we only have the tags for when the code is part of the Apache foundation? I agree that the headers docs and other pieces will need to be updated. Is there an official list of things we should do before tagging the first release? > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109983#comment-16109983 ] Julian Hyde commented on CALCITE-1240: -- Vote is in progress now. [~francischuang], When the vote finishes, what are the next steps? Would you like an empty git repo (into which you can load the latest source) or a repo that is a copy of https://github.com/boostport/avatica? Then I think we should make sure files have Apache headers, update documentation, create a release history page, and create a release candidate, update Avatica's web site. What do you think? > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1916) Use TPC-DS generator and run tests against TPC-DS at small scale
Julian Hyde created CALCITE-1916: Summary: Use TPC-DS generator and run tests against TPC-DS at small scale Key: CALCITE-1916 URL: https://issues.apache.org/jira/browse/CALCITE-1916 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Use TPC-DS generator and run tests against TPC-DS at small scale. I previously started one at https://github.com/julianhyde/tpcds but Teradata have written a better one at https://github.com/Teradata/tpcds. We can use it in the same way that we use https://github.com/airlift/tpch for TPC-H. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1915) Workaround Jetty SpnegoAuthenticator bug where no challenge is sent
Josh Elser created CALCITE-1915: --- Summary: Workaround Jetty SpnegoAuthenticator bug where no challenge is sent Key: CALCITE-1915 URL: https://issues.apache.org/jira/browse/CALCITE-1915 Project: Calcite Issue Type: Bug Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.11.0 I stumbled across what I think is a bug in Jetty per the RFC-7616. The RFC reads (to me) as the following: When a client sends an authorization header that is not capable of being used to authenticate via SPNEGO, the server should send back the WWW-Authentication: Negotiate HTTP header with a status code of HTTP/401. Jetty will only send this challenge+401 when *no* Authorization header is provided. In the case where Avatica is sitting behind a reverse-proxy, the proxy _may_ choose to pass along another authorization header. Jetty (and Avatica) should still respond to say "You need to authenticate over SPNEGO". At least Jetty dev seems to agree with my assessment: https://github.com/eclipse/jetty.project/issues/1698. We can easily work around this in Avatica while we wait to get a Jetty release which has this fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[
https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109836#comment-16109836
]
Julian Hyde commented on CALCITE-1912:
--
This feature would cover temporal support as described in SQL:2011, and
implemented in Oracle (among others).
Joins of streams to temporal tables (e.g. joining the Orders stream to the
Products table for the price as of the time the order was placed) is outside
the scope of this case.
If possible, I would very much like this feature to go beyond SQL parsing and
validation, and to be able to execute temporal queries in core Calcite. This
implies that we would have a temporal table in one of the standard data sets.
And we would have a way of declaring a temporal table in a JSON model file.
Here is an example:
{code}
"tables": [
{
"name": "TEMPORAL_EMPS",
"type": "custom",
"factory": "org.apache.calcite.adapter.csv.CsvTableFactory",
"temporal": {
"start": "EMP_VT_TIME_START",
"end": "EMP_VT_TIME_END"
}
}
]
{code}
To implement
{code}SELECT empno, sal
FROM TEMPORAL_EMPS FOR SYSTEM_TIME AS OF DATE '2017-02-03'{code}
Calcite would generate a plan equivalent to
{code}SELECT empno, sal
FROM TEMPORAL_EMPS
WHERE EMP_VT_TIME_START <= DATE '2017-02-03'
AND (EMP_VT_TIME_END IS NULL
OR EMP_VT_TIME_END > DATE '2017-02-03'){code}
> Support "FOR SYSTEM_TIME AS OF" in regular queries
> --
>
> Key: CALCITE-1912
> URL: https://issues.apache.org/jira/browse/CALCITE-1912
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF"
> in Calcite to retrieve table contents as of a given point in time.
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1914) Create a DOAP file for Avatica
Julian Hyde created CALCITE-1914: Summary: Create a DOAP file for Avatica Key: CALCITE-1914 URL: https://issues.apache.org/jira/browse/CALCITE-1914 Project: Calcite Issue Type: Bug Components: avatica, site Reporter: Julian Hyde Create a [DOAP (Description of a Project)|https://projects.apache.org/doap.html] file for Avatica. As an example, here is Calcite's: * https://projects.apache.org/project.html?calcite * https://github.com/apache/calcite/blob/master/site/doap_calcite.rdf Instructions are here: https://projects.apache.org/about.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1913) Include DB version in SqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109704#comment-16109704
]
Jess Balint commented on CALCITE-1913:
--
People may choose not to use a feature if it's buggy? This would mean dialects
are not only a reflection of the SQL dialect, but also user preferences?
So let's look at some examples here.
First, we see {{JdbcRules}} maintaining two sets of aggregates:
{code:java}
static final ImmutableList AGG_FUNCS;
static final ImmutableList MYSQL_AGG_FUNCS;
{code}
and choosing between these based on DB product:
{code:java}
switch (sqlDialect.getDatabaseProduct()) {
case MYSQL:
return MYSQL_AGG_FUNCS.contains(aggregation.getKind());
default:
return AGG_FUNCS.contains(aggregation.getKind());
}
{code}
Sure, we can encapsulate the set of aggregate functions behind the
{{SqlDialect}} API and a add a subclass for MySQL (version-independent). Would
it make sense here? I don't have a preference.
Something like {{SqlImplementor.rewriteSingleValueExpr()}} uses:
{code:java}
switch (sqlDialect.getDatabaseProduct()) {
case MYSQL:
case HSQLDB:
{code}
here, we can encapsulate this with either a {{boolean
supportsSingleValueRewrite()}} method or adding {{rewriteSingleValueExpr()}} to
the dialect.
However, in my application, I have something very similar to test for support
of {{FETCH}}. SQL Server 2008 doesn't support it. I can either ask for the
version from the dialect:
{code:java}
switch (dialect.getDatabaseProduct()) {
case MSSQL:
return dialect.getDatabaseMajorVersion() >= 11;
{code}
or add a new method to {{SqlDialect}} such as {{supportsFetch()}} (with
different semantics than the current {{supportsOffsetFetch()}})). Version is
also required when deciding how to translate functions, e.g. SQL Server 2012
supports n-ary {{CONCAT()}} but SQL Server 2008 needs to use {{+}}. If
{{SqlDialect}} doesn't expose version, then what? Add {{supportsNaryConcat()}}
or have each dialect maintain it's own operator table?
> Include DB version in SqlDialect
>
>
> Key: CALCITE-1913
> URL: https://issues.apache.org/jira/browse/CALCITE-1913
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.0
>Reporter: Jess Balint
>Assignee: Jess Balint
>Priority: Minor
> Fix For: 1.14.0
>
>
> It would be useful to have the DB version # in the SqlDialect for unparsing
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1913) Include DB version in SqlDialect
[ https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109586#comment-16109586 ] Julian Hyde commented on CALCITE-1913: -- Yep, exposing the DB product was an intentional leak in the abstraction. For some things, it's just more straightforward to have an enum to put in a switch statement. But that doesn't mean I'm OK widening the leak to a gaping hole. > Include DB version in SqlDialect > > > Key: CALCITE-1913 > URL: https://issues.apache.org/jira/browse/CALCITE-1913 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.13.0 >Reporter: Jess Balint >Assignee: Jess Balint >Priority: Minor > Fix For: 1.14.0 > > > It would be useful to have the DB version # in the SqlDialect for unparsing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1913) Include DB version in SqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109555#comment-16109555
]
Jess Balint commented on CALCITE-1913:
--
You could argue the same for exposing the DB product from the {{SqlDialect}}.
The low-level details are exposed for others - whether it's a CALCITE-1841
{{Handler}}, or other (3rd party) code - to build those abstractions. This
doesn't prevent us from adding more methods to a dialect to determine behavior
(e.g. the existing {{supportsOffsetFetch()}}, {{allowsAs()}},
{{requiresAliasForFromItems()}}, etc).
> Include DB version in SqlDialect
>
>
> Key: CALCITE-1913
> URL: https://issues.apache.org/jira/browse/CALCITE-1913
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.0
>Reporter: Jess Balint
>Assignee: Jess Balint
>Priority: Minor
> Fix For: 1.14.0
>
>
> It would be useful to have the DB version # in the SqlDialect for unparsing
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1913) Include DB version in SqlDialect
[ https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jess Balint updated CALCITE-1913: - Priority: Minor (was: Major) > Include DB version in SqlDialect > > > Key: CALCITE-1913 > URL: https://issues.apache.org/jira/browse/CALCITE-1913 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.13.0 >Reporter: Jess Balint >Assignee: Jess Balint >Priority: Minor > Fix For: 1.14.0 > > > It would be useful to have the DB version # in the SqlDialect for unparsing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1913) Include DB version in SqlDialect
Jess Balint created CALCITE-1913: Summary: Include DB version in SqlDialect Key: CALCITE-1913 URL: https://issues.apache.org/jira/browse/CALCITE-1913 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.13.0 Reporter: Jess Balint Assignee: Jess Balint Fix For: 1.14.0 It would be useful to have the DB version # in the SqlDialect for unparsing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1909) The output rowType should also include partition by and order by key columns
[
https://issues.apache.org/jira/browse/CALCITE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108501#comment-16108501
]
Zhiqiang He commented on CALCITE-1909:
--
It is a bug. I will fix it later.
> The output rowType should also include partition by and order by key columns
>
>
> Key: CALCITE-1909
> URL: https://issues.apache.org/jira/browse/CALCITE-1909
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> According to the documentation, the output rowType should also include
> partition by key columns and order by key columns.
> {quote}
> MATCH_RECOGNIZE is called the row pattern output table. The shape (row type)
> of the row pattern output table depends on the choice of ONE ROW PER MATCH or
> ALL ROWS PER MATCH:
> * If ONE ROW PER MATCH is specied or implied, then the columns of the row
> pattern output table are the row pattern partitioning columns in their order
> of declaration, followed by the row pattern measure columns in their order of
> declaration. Since a table must have at least one column, this implies that
> there must be at least one row pattern partitioning column or one row pattern
> measure column.
> * If ALL ROWS PER MATCH is speci ed, then the columns of the row pattern
> output table are the row pattern partitioning columns in their order of
> declaration, the ordering columns in their order of declaration, the row
> pattern measure columns in their order of declaration, and nally any
> remaining columns of the row pattern input table, in the order they occur in
> the row pattern input table.
> {quote}
> Currently, partition key columns and order by key columns are not included in
> the output row type.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-1909) The output rowType should also include partition by and order by key columns
[
https://issues.apache.org/jira/browse/CALCITE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhiqiang He reassigned CALCITE-1909:
Assignee: Zhiqiang He (was: Julian Hyde)
> The output rowType should also include partition by and order by key columns
>
>
> Key: CALCITE-1909
> URL: https://issues.apache.org/jira/browse/CALCITE-1909
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Zhiqiang He
> Labels: match
>
> According to the documentation, the output rowType should also include
> partition by key columns and order by key columns.
> {quote}
> MATCH_RECOGNIZE is called the row pattern output table. The shape (row type)
> of the row pattern output table depends on the choice of ONE ROW PER MATCH or
> ALL ROWS PER MATCH:
> * If ONE ROW PER MATCH is specied or implied, then the columns of the row
> pattern output table are the row pattern partitioning columns in their order
> of declaration, followed by the row pattern measure columns in their order of
> declaration. Since a table must have at least one column, this implies that
> there must be at least one row pattern partitioning column or one row pattern
> measure column.
> * If ALL ROWS PER MATCH is speci ed, then the columns of the row pattern
> output table are the row pattern partitioning columns in their order of
> declaration, the ordering columns in their order of declaration, the row
> pattern measure columns in their order of declaration, and nally any
> remaining columns of the row pattern input table, in the order they occur in
> the row pattern input table.
> {quote}
> Currently, partition key columns and order by key columns are not included in
> the output row type.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
Jark Wu created CALCITE-1912: Summary: Support "FOR SYSTEM_TIME AS OF" in regular queries Key: CALCITE-1912 URL: https://issues.apache.org/jira/browse/CALCITE-1912 Project: Calcite Issue Type: New Feature Reporter: Jark Wu Assignee: Julian Hyde As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" in Calcite to retrieve table contents as of a given point in time. [1] https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
