[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254396#comment-17254396 ] Josh Elser commented on CALCITE-4152: - I guess this approach is really just a JWT but not following that spec [https://jwt.io/introduction] Maybe step 5 should be "make it a JWT" > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Priority: Major > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-4152: --- Assignee: Josh Elser > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Assignee: Josh Elser >Priority: Major > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4424) Complete non-deterministic function in SqlFunction
[
https://issues.apache.org/jira/browse/CALCITE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252300#comment-17252300
]
Jiatao Tao edited comment on CALCITE-4424 at 12/24/20, 3:13 AM:
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction).
{code:java}
* Returns whether it is unsafe to cache query plans referencing this
* operator; false is assumed by default
{code}
The isDynamicFunction's def is pretty clear, where to use is clear, it's an
independent interface, I think they have no relationship, so this Jira will not
care about isDynamicFunction.
was (Author: aron.tao):
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction).
{code:java}
* Returns whether it is unsafe to cache query plans referencing this
* operator; false is assumed by default
{code}
The isDynamicFunction's def is pretty clear, where to use is clear, I think
they have no relationship, so this Jira will not care about isDynamicFunction.
> Complete non-deterministic function in SqlFunction
> --
>
> Key: CALCITE-4424
> URL: https://issues.apache.org/jira/browse/CALCITE-4424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current only SqlSequenceValueOperator override isDeterministic, func like
> RAND doesn't override isDeterministic
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[
https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254375#comment-17254375
]
Josh Elser commented on CALCITE-4152:
-
Looking at this for fun, the general wag at what Hadoop is doing is this...
* After a successful SPNEGO auth'n, they send a SetCookie header back to the
client
* The cookie looks something like {{Set-Cookie:
hadoop.auth="u=guest=guest/c6401.ambari.apache@example.com=kerberos=1487947765114=fNpq9FYy2DA19Rah7586rgsAieI=";
Path=gateway/default; Domain=ambari.apache.org; Secure; HttpOnly}}
* The token data is "username", (kerberos) "principal", authentication type,
expiration time
* This token data is signed with HmacSHA256 and that's included as
"{{fNpq9FYy2DA19Rah7586rgsAieI="}}
* The signature is used when the token is passed back to the server to
validate that the token itself wasn't changed (e.g. user doesn't modify it and
say they're someone else)
* If the user doesn't provide the token (via the cookie), spnego authn happens
normally. When spnego authn succeeds, it sets a new cookie
* If the user provides the token (via the cookie) and the token is valid (the
signature matches), then user is marked as "authenticated" (as the user who is
specified in that auth token).
I think I can break this up into a couple of steps:
# Show that we can bypass spnego successfully with a cookie that just has
basic info. Will have to add indirection in AbstractAvaticaHandler to not pull
the user directly from the HttpServletRequest. Update the client, maybe (the
http client we use may automatically pass it along)?
# Make the plan cookie data into a protobuf or other serializable data
structure
# Add signing of the cookie data
# Add expiration of the auth cookie
> Avoid SPNEGO re-negotiation for each request
>
>
> Key: CALCITE-4152
> URL: https://issues.apache.org/jira/browse/CALCITE-4152
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Istvan Toth
>Priority: Major
>
> When using SPNEGO authentication with Avatica, every HTTP request
> re-initiates the negotiation, doubling the number HTTP requests.
> Consider switching to cookies after the initial SPNEGO authentication
> succeeds.
> Jetty ticket that discusses the issue:
> [https://github.com/eclipse/jetty.project/issues/2868]
> Description of the Knox implementation
> [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4432) When the RelNode's input is the same subset as the node belonged to, not choose this node as best.
[ https://issues.apache.org/jira/browse/CALCITE-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254371#comment-17254371 ] Liya Fan commented on CALCITE-4432: --- [~rubenql] It seems the problem you are facing is similar to the one reported in this issue: problem with the cost model => the cost of a child greater than that of its parent => the parent node is selected as the best of the child's RelSubset => a cycle is formed > When the RelNode's input is the same subset as the node belonged to, not > choose this node as best. > -- > > Key: CALCITE-4432 > URL: https://issues.apache.org/jira/browse/CALCITE-4432 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Ziwei Liu >Assignee: Ziwei Liu >Priority: Major > > If a subset have a cyclic node, the node's input is this subset itself. If > the beset -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4425) Class DefaultEdge lacks a proper toString implementation
[
https://issues.apache.org/jira/browse/CALCITE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254368#comment-17254368
]
Liya Fan commented on CALCITE-4425:
---
[~julianhyde] Sure. I will be mindful next time. Thanks for your kind reminder.
> Class DefaultEdge lacks a proper toString implementation
>
>
> Key: CALCITE-4425
> URL: https://issues.apache.org/jira/browse/CALCITE-4425
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Liya Fan
>Assignee: Liya Fan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It is convenient to build a graph as an object of {{DefaultDirectedGraph}}.
> The class has a good {{toString}} implementation, which greatly helps
> examining the structure of the graph.
> However, the output of the method may be confusing. In our system, the
> {{toString}} method produces the following result:
> graph(vertices: [0, 1, 2, 3, 4, 5, 6], edges:
> [org.apache.calcite.util.graph.DefaultEdge@1a550334,
> org.apache.calcite.util.graph.DefaultEdge@891ce8a1,
> org.apache.calcite.util.graph.DefaultEdge@ba5c5190,
> org.apache.calcite.util.graph.DefaultEdge@c894f6b3,
> org.apache.calcite.util.graph.DefaultEdge@d72993fe,
> org.apache.calcite.util.graph.DefaultEdge@da030cc4,
> org.apache.calcite.util.graph.DefaultEdge@de17986f,
> org.apache.calcite.util.graph.DefaultEdge@e20be355,
> org.apache.calcite.util.graph.DefaultEdge@ef7b8a83,
> org.apache.calcite.util.graph.DefaultEdge@f2b672ef,
> org.apache.calcite.util.graph.DefaultEdge@f547e446])
> The reason is that the default edge type is {{DefaultEdge}}, and the
> {{DefaultEdge}} class does not have a proper {{toString}} implementation. So
> we want to provide one, so that it helps investigating the internals of the
> graph.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254361#comment-17254361
]
Josh Elser commented on CALCITE-4367:
-
Pull request is up. If I don't get a review, I'll plan on committing this in a
few days.
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254357#comment-17254357
]
Josh Elser edited comment on CALCITE-4367 at 12/24/20, 1:47 AM:
{quote}
`RpcMetadata` is actually a response as opposed to a miscellaneous type per
[here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
and thus requires a {{response}} field. Note I'm not certain if this was
intentional, i.e., it being a response, however it it is it seems that it
should be renamed to {{RpcMetadataResponse}} for consistency.
{quote}
It's intentional that it isn't a response, as a "Response" was intended to be
top-level messages which might be sent back by the Avatica server. However,
it's not used by any requests, so it lives in responses.proto to avoid
polluting common.proto (for no reason). Hope this makes sense. I'll update the
comment to reflect this.
bq. The supplied ConnectionProperties contains an undocumented dirty field
(is_dirty for protobuf).
Good catch. Another funny one -- this shouldn't ever be sent over the wire.
It's just internal state used to avoid unnecessary RPCs (to sync the client's
properties with the properties in the Avatica server). I'll update the docs for
now, but we should circle back to avoid this getting serialized at all (for
json and proto)
The rest of these were spot-on. Thanks for the easy-to-incorporate feedback,
[~john.bod...@gmail.com]
was (Author: elserj):
{quote}
`RpcMetadata` is actually a response as opposed to a miscellaneous type per
[here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
and thus requires a {{response}} field. Note I'm not certain if this was
intentional, i.e., it being a response, however it it is it seems that it
should be renamed to {{RpcMetadataResponse}} for consistency.
It's intentional that it isn't a response, as a "Response" was intended to be
top-level messages which might be sent back by the Avatica server. However,
it's not used by any requests, so it lives in responses.proto to avoid
polluting common.proto (for no reason). Hope this makes sense. I'll update the
comment to reflect this.
bq. The supplied ConnectionProperties contains an undocumented dirty field
(is_dirty for protobuf).
Good catch. Another funny one -- this shouldn't ever be sent over the wire.
It's just internal state used to avoid unnecessary RPCs (to sync the client's
properties with the properties in the Avatica server). I'll update the docs for
now, but we should circle back to avoid this getting serialized at all (for
json and proto)
The rest of these were spot-on. Thanks for the easy-to-incorporate feedback,
[~john.bod...@gmail.com]
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254357#comment-17254357
]
Josh Elser commented on CALCITE-4367:
-
{quote}
`RpcMetadata` is actually a response as opposed to a miscellaneous type per
[here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
and thus requires a {{response}} field. Note I'm not certain if this was
intentional, i.e., it being a response, however it it is it seems that it
should be renamed to {{RpcMetadataResponse}} for consistency.
It's intentional that it isn't a response, as a "Response" was intended to be
top-level messages which might be sent back by the Avatica server. However,
it's not used by any requests, so it lives in responses.proto to avoid
polluting common.proto (for no reason). Hope this makes sense. I'll update the
comment to reflect this.
bq. The supplied ConnectionProperties contains an undocumented dirty field
(is_dirty for protobuf).
Good catch. Another funny one -- this shouldn't ever be sent over the wire.
It's just internal state used to avoid unnecessary RPCs (to sync the client's
properties with the properties in the Avatica server). I'll update the docs for
now, but we should circle back to avoid this getting serialized at all (for
json and proto)
The rest of these were spot-on. Thanks for the easy-to-incorporate feedback,
[~john.bod...@gmail.com]
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-4367:
---
Assignee: Josh Elser
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4446) Implement three-valued logic for SEARCH operator
[
https://issues.apache.org/jira/browse/CALCITE-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4446:
-
Description:
Implement three-valued logic for SEARCH operator.
Consider the expression {{x IN (10, 20)}}, which we might represent as
{{SEARCH(x, Sarg(10, 20))}}. Suppose we invoke this with a value of {{NULL}}
for {{x}}. Do we want it to return UNKNOWN, FALSE or TRUE? The answer is: all
of the above.
Here are the 3 variants:
* {{Sarg(10, 20, UNKNOWN AS TRUE)}}: {{x IS NULL OR x IN (10, 20)}} TRUE
* {{Sarg(10, 20, UNKNOWN AS UNKNOWN)}}: {{x IN (10, 20)}} UNKNOWN
* {{Sarg(10, 20, UNKNOWN AS FALSE)}}: {{x IS NOT NULL AND (x IN (10, 20))}}
FALSE
Currently {{class Sarg}} has a field {{boolean containsNull}} which deals with
the first two cases. Changing {{boolean containsNull}} to {{RexUnknownAs
unknownAs}} (which has 3 values) will allow us to represent the third. The new
representation is symmetrical under negation, which de Morgan's law suggests is
a good thing.
was:
Implement three-valued logic for SEARCH operator.
Consider the expression {{x IN (10, 20)}}, which we might represent as
{{SEARCH(x, SARG(10, 20))}}. Suppose we invoke this with a value of {{NULL}}
for {{x}}. Do we want it to return UNKNOWN, FALSE or TRUE? The answer is: all
of the above.
Here are the 3 variants:
* {{SEARCH(10, 20, UNKNOWN AS TRUE)}}: {{x IS NULL OR x IN (10, 20)}}
TRUE
* {{SEARCH(10, 20, UNKNOWN AS UNKNOWN)}}: {{x IN (10, 20)}} UNKNOWN
* {{SEARCH(10, 20, UNKNOWN AS FALSE)}}: {{x IS NOT NULL AND (x IN (10, 20))}}
FALSE
Currently {{class Sarg}} has a field {{boolean containsNull}} which deals with
the first two cases. Changing {{boolean containsNull}} to {{RexUnknownAs
unknownAs}} (which has 3 values) will allow us to represent the third. The new
representation is symmetrical under negation, which de Morgan's law suggests is
a good thing.
> Implement three-valued logic for SEARCH operator
> -
>
> Key: CALCITE-4446
> URL: https://issues.apache.org/jira/browse/CALCITE-4446
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Implement three-valued logic for SEARCH operator.
> Consider the expression {{x IN (10, 20)}}, which we might represent as
> {{SEARCH(x, Sarg(10, 20))}}. Suppose we invoke this with a value of {{NULL}}
> for {{x}}. Do we want it to return UNKNOWN, FALSE or TRUE? The answer is: all
> of the above.
> Here are the 3 variants:
> * {{Sarg(10, 20, UNKNOWN AS TRUE)}}: {{x IS NULL OR x IN (10, 20)}}
> TRUE
> * {{Sarg(10, 20, UNKNOWN AS UNKNOWN)}}: {{x IN (10, 20)}} UNKNOWN
> * {{Sarg(10, 20, UNKNOWN AS FALSE)}}: {{x IS NOT NULL AND (x IN (10, 20))}}
> FALSE
> Currently {{class Sarg}} has a field {{boolean containsNull}} which deals
> with the first two cases. Changing {{boolean containsNull}} to {{RexUnknownAs
> unknownAs}} (which has 3 values) will allow us to represent the third. The
> new representation is symmetrical under negation, which de Morgan's law
> suggests is a good thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4446) Implement three-valued logic for SEARCH operator
Julian Hyde created CALCITE-4446:
Summary: Implement three-valued logic for SEARCH operator
Key: CALCITE-4446
URL: https://issues.apache.org/jira/browse/CALCITE-4446
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Implement three-valued logic for SEARCH operator.
Consider the expression {{x IN (10, 20)}}, which we might represent as
{{SEARCH(x, SARG(10, 20))}}. Suppose we invoke this with a value of {{NULL}}
for {{x}}. Do we want it to return UNKNOWN, FALSE or TRUE? The answer is: all
of the above.
Here are the 3 variants:
* {{SEARCH(10, 20, UNKNOWN AS TRUE)}}: {{x IS NULL OR x IN (10, 20)}}
TRUE
* {{SEARCH(10, 20, UNKNOWN AS UNKNOWN)}}: {{x IN (10, 20)}} UNKNOWN
* {{SEARCH(10, 20, UNKNOWN AS FALSE)}}: {{x IS NOT NULL AND (x IN (10, 20))}}
FALSE
Currently {{class Sarg}} has a field {{boolean containsNull}} which deals with
the first two cases. Changing {{boolean containsNull}} to {{RexUnknownAs
unknownAs}} (which has 3 values) will allow us to represent the third. The new
representation is symmetrical under negation, which de Morgan's law suggests is
a good thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4425) Class DefaultEdge lacks a proper toString implementation
[
https://issues.apache.org/jira/browse/CALCITE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254204#comment-17254204
]
Julian Hyde commented on CALCITE-4425:
--
The commit message seems a bit snide, especially when it read as part of the
release notes. Please try to keep a neutral tone.
> Class DefaultEdge lacks a proper toString implementation
>
>
> Key: CALCITE-4425
> URL: https://issues.apache.org/jira/browse/CALCITE-4425
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Liya Fan
>Assignee: Liya Fan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It is convenient to build a graph as an object of {{DefaultDirectedGraph}}.
> The class has a good {{toString}} implementation, which greatly helps
> examining the structure of the graph.
> However, the output of the method may be confusing. In our system, the
> {{toString}} method produces the following result:
> graph(vertices: [0, 1, 2, 3, 4, 5, 6], edges:
> [org.apache.calcite.util.graph.DefaultEdge@1a550334,
> org.apache.calcite.util.graph.DefaultEdge@891ce8a1,
> org.apache.calcite.util.graph.DefaultEdge@ba5c5190,
> org.apache.calcite.util.graph.DefaultEdge@c894f6b3,
> org.apache.calcite.util.graph.DefaultEdge@d72993fe,
> org.apache.calcite.util.graph.DefaultEdge@da030cc4,
> org.apache.calcite.util.graph.DefaultEdge@de17986f,
> org.apache.calcite.util.graph.DefaultEdge@e20be355,
> org.apache.calcite.util.graph.DefaultEdge@ef7b8a83,
> org.apache.calcite.util.graph.DefaultEdge@f2b672ef,
> org.apache.calcite.util.graph.DefaultEdge@f547e446])
> The reason is that the default edge type is {{DefaultEdge}}, and the
> {{DefaultEdge}} class does not have a proper {{toString}} implementation. So
> we want to provide one, so that it helps investigating the internals of the
> graph.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4443) Add support for the ILIKE operator to core
[ https://issues.apache.org/jira/browse/CALCITE-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254154#comment-17254154 ] Ondřej Štumpf commented on CALCITE-4443: I updated the PR, please take a look when it suits you. > Add support for the ILIKE operator to core > -- > > Key: CALCITE-4443 > URL: https://issues.apache.org/jira/browse/CALCITE-4443 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Ondřej Štumpf >Assignee: Ondřej Štumpf >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Extend the list of supported relational operators in SqlStdOperatorTable with > ILIKE. The new ILIKE keyword should be unreserved and behave exactly like > LIKE, but without case-sensitivity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4432) When the RelNode's input is the same subset as the node belonged to, not choose this node as best.
[ https://issues.apache.org/jira/browse/CALCITE-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254136#comment-17254136 ] Ruben Q L commented on CALCITE-4432: UPDATE: finally I discovered the root cause of my CyclicMetadataException: it was also a metadata cost computation problem. At some point during Volcano optimization, an operator had a lower cost than its input's cost. The reason for this anomaly was a bug in the RelMdColumnUniqueness computation of a certain IndexScan operator in my downstream project. > When the RelNode's input is the same subset as the node belonged to, not > choose this node as best. > -- > > Key: CALCITE-4432 > URL: https://issues.apache.org/jira/browse/CALCITE-4432 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Ziwei Liu >Assignee: Ziwei Liu >Priority: Major > > If a subset have a cyclic node, the node's input is this subset itself. If > the beset -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4445) Create new conformance level for Postgresql
Ondřej Štumpf created CALCITE-4445:
--
Summary: Create new conformance level for Postgresql
Key: CALCITE-4445
URL: https://issues.apache.org/jira/browse/CALCITE-4445
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Ondřej Štumpf
Assignee: Ondřej Štumpf
In CALCITE-4443, a new Postgresql-specific operator {{ILIKE}} was introduced.
Currently that operator is only enabled in {{LENIENT}} and {{BABEL}}
conformance levels. Let's:
* create a new conformance level {{POSTGRESQL}}
** make sure it supports {{ILIKE}}
* use this new conformance level in Postgresql and Vertica dialects
* update the tests for {{ILIKE}} to set {{POSTGRESQL}} conformance level
instead of {{LENIENT}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3809) RexSimplify simplifies nondeterministic function incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253948#comment-17253948
]
Chunwei Lei commented on CALCITE-3809:
--
You have a point. I already forgot the reason for this change. Feel free to
restore it.
> RexSimplify simplifies nondeterministic function incorrectly
>
>
> Key: CALCITE-3809
> URL: https://issues.apache.org/jira/browse/CALCITE-3809
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.23.0
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> For example, {{rand() = rand()}} will be simplified to {{IS NOT
> NULL(rand())}}, which is wrong because {{rand() = rand()}} might be false
> while {{IS NOT NULL(rand())}} is always true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
