+1 for “pull-request-available”.
On Tue, Jan 8, 2019 at 2:13 PM Jark Wu wrote:
> +1 for "pull-request-available"
>
>
> On Tue, 8 Jan 2019 at 05:33, Francis Chuang
> wrote:
>
> > +1 for "pull-request-available"
> >
> > On 8/01/2019 8:13 am, Julian Hyde wrote:
> > > There seem to be two
+1 for "pull-request-available"
On Tue, 8 Jan 2019 at 05:33, Francis Chuang
wrote:
> +1 for "pull-request-available"
>
> On 8/01/2019 8:13 am, Julian Hyde wrote:
> > There seem to be two mechanisms to indicate that a pull-request is
> available for a JIRA case.
> >
> > 1. The “Patch” flag (13
F21 closed pull request #36: [CALCITE-2775] Upgrade dependencies and regenerate
protobufs
URL: https://github.com/apache/calcite-avatica-go/pull/36
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
F21 opened a new pull request #36: [CALCITE-2775] Upgrade dependencies and
regenerate protobufs
URL: https://github.com/apache/calcite-avatica-go/pull/36
This is an automated message from the Apache Git Service.
To respond
Francis Chuang created CALCITE-2775:
---
Summary: Update dependencies and regenerate protobufs
Key: CALCITE-2775
URL: https://issues.apache.org/jira/browse/CALCITE-2775
Project: Calcite
Issue
The sql.NullString [1] type exists for this. There are a few other ones:
NullFloat64, NullInt64 and NullBool.
However, while it does exist, we're at the mercy of Phoenix. Since
Phoenix only returns a Rep_Type of Null and null = true regardless of
whether the string is empty or an actual null,
Francis Chuang created CALCITE-2774:
---
Summary: Improve release documentation for Avatica-Go
Key: CALCITE-2774
URL: https://issues.apache.org/jira/browse/CALCITE-2774
Project: Calcite
Issue
OK, it seems you’ve given this plenty of thought.
I don’t know Go, but it seems that string values can never be null, in the same
way that int values cannot be null in Java. But SQL INTEGER columns can have
NULL values, so JDBC needs a way to represent the NULL values on the client. In
JDBC,
I have had instances where replies to messages on Apache mailing lists
went into my spam folder.
@Hermakumar, if you did not see Michael's reply in your inbox, please
check your spam folder. There is an archive of his message here:
This behavior is the default for Phoenix and will only apply to Phoenix.
Unfortunately, I don't think there it would be possible to turn this
behavior on or off in the Go client as there is no way to distinguish a
null and an empty string that is being returned by Avatica.
This is what the Go
Sorry, my bad moderating it through this time.
> On Jan 7, 2019, at 1:34 PM, Josh Elser wrote:
>
> Please read Michael's reply to you from the first time you sent this message
> instead of sending it again.
>
> Let's not moderate this through a third time.
>
> On 1/7/19 4:06 PM, Hemakumar
+1 for "pull-request-available"
On 8/01/2019 8:13 am, Julian Hyde wrote:
There seem to be two mechanisms to indicate that a pull-request is available
for a JIRA case.
1. The “Patch” flag (13 issues); see
> “pull-request-available”
+1
Vladimir
Julian> No, it is not the “unknown collation” subset. It is more like
the “don’t care” subset.
Would you please care to explain how the following is possible? (it is
from the start of the thread)
LogicalProject(subset=[rel#11:Subset#1.NONE.[0]],
input=rel#9:Subset#0.NONE.[], Y=[$1])
I read
No, it is not the “unknown collation” subset. It is more like the “don’t care”
subset.
Traits are a form of quality-of-service. Like when you order a package, you can
pay extra for 2-day shipping, and even more for 1-day shipping. You pay more
for a tighter guarantee.
The subset with
Julian> I don’t think the [] means “no collation”. It means “order by
zero columns”. The list of columns is present, but it is empty.
I agree I might be wrong from technical point of view. Frankly
speaking, I don't think I've ever understood what Calcite traits are
even though I happen to land a
How this behavior enabled?
Apache Phoenix’s behavior contravenes the SQL standard (which states that empty
strings and null strings are different) and so clients must not get this
behavior unless they ask for it. It would be OK if they get it by default for
Phoenix, but even then, there should
I don’t think the [] means “no collation”. It means “order by zero columns”.
The list of columns is present, but it is empty.
Of course, this “empty collation” provides no guarantees as to the ordering of
rows. It is a collation; it’s just the weakest possible collation.
> On Jan 7, 2019, at
Vladimir Sitnikov created CALCITE-2773:
--
Summary: Prune of empty values causes assertion error "rel cost is
lower than best cost"
Key: CALCITE-2773
URL: https://issues.apache.org/jira/browse/CALCITE-2773
This is the sort of situation I'm hoping the notebooks I recently published
will be useful for (link below). I haven't written up any documentation yet
but you can click through to any of the notebooks to see pre-generated
output or click one of the launch buttons to modify the code and play with
Hi Vladimir,
>From the analysis so far, the following part caught my attention:
Vladimir>So far so good, however the RelSubset for LogicalValues is awkward:
rel#9:Subset#0.NONE.[]
[] means "no collation". In other words, it puts "multi-collated" values
into a subset that has "no" collation.
...
21 matches
Mail list logo
