Hey @Chunwei Lei,
Sorry, I forgot to mention my Jira id (pranay.parmar). Thanks, @Francis
Chuang for adding me to the list.
Pranay
On Fri, Dec 20, 2019 at 12:12 PM Francis Chuang
wrote:
> Hey,
>
> I added you as a contributor. I think your username is pranay.parmar as
> there's only one user
Thanks Zhenghua sharing [1], which really explaining three different
semantics of TIMESTAMP and clarified some of my long term confusion about
TIMESTAMP.
Julian> We need all 3, regardless of what they are called
Can I confirm that Calcite already have the following two semantics support:
1.
Hey,
I added you as a contributor. I think your username is pranay.parmar as
there's only one user under your name.
Francis
On 20/12/2019 5:20 pm, Pranay Parmar wrote:
Hi,
I would like to be added to the JIRA/GitHub contributors list. I have a
pull request raised but not able to assign
Hi, Pranay.
You should provide your jira id so that someone can add you as a
contributor.
Best,
Chunwei
On Fri, Dec 20, 2019 at 2:20 PM Pranay Parmar
wrote:
> Hi,
>
> I would like to be added to the JIRA/GitHub contributors list. I have a
> pull request raised but not able to assign myself.
Hi,
I would like to be added to the JIRA/GitHub contributors list. I have a
pull request raised but not able to assign myself. I don't want somebody
else to pick it because I've been working on it.
Thanks and regards,
Pranay Parmar
Ritesh created CALCITE-3616:
---
Summary: Add BOOL_AND Aggregate Function
Key: CALCITE-3616
URL: https://issues.apache.org/jira/browse/CALCITE-3616
Project: Calcite
Issue Type: New Feature
Ritesh created CALCITE-3617:
---
Summary: Add BOOL_OR Aggregate Function
Key: CALCITE-3617
URL: https://issues.apache.org/jira/browse/CALCITE-3617
Project: Calcite
Issue Type: New Feature
Zhenghua Gao created CALCITE-3615:
-
Summary: Improve JDBC driver to support java.time classes
Key: CALCITE-3615
URL: https://issues.apache.org/jira/browse/CALCITE-3615
Project: Calcite
Issue
Zhenghua Gao created CALCITE-3614:
-
Summary: Support TIME/TIMESTAMP WITH TIME ZONE literals
Key: CALCITE-3614
URL: https://issues.apache.org/jira/browse/CALCITE-3614
Project: Calcite
Issue
Zhenghua Gao created CALCITE-3613:
-
Summary: Support TIME/TIMESTAMP WITH TIME ZONE in Calcite SQL
parser and builtin functions
Key: CALCITE-3613
URL: https://issues.apache.org/jira/browse/CALCITE-3613
Zhenghua Gao created CALCITE-3612:
-
Summary: Add TIME/TIMESTAMP WITH TIME ZONE in optimizer
Key: CALCITE-3612
URL: https://issues.apache.org/jira/browse/CALCITE-3612
Project: Calcite
Issue
Thanks for your comments!
I have opened an umbrella issue[1] to track this.
[1] https://issues.apache.org/jira/browse/CALCITE-3611
*Best Regards,*
*Zhenghua Gao*
On Fri, Dec 20, 2019 at 4:05 AM Julian Hyde wrote:
> It would be great to have a timestamp type with (timeZone, number) data
>
Zhenghua Gao created CALCITE-3611:
-
Summary: Introduce TIME/TIMESTAMP WITH TIME ZONE types
Key: CALCITE-3611
URL: https://issues.apache.org/jira/browse/CALCITE-3611
Project: Calcite
Issue
From past experience, I think it the files should become available as
long as the repository is marked as released within nexus, so this
shouldn't be too much of a problem.
On 20/12/2019 9:18 am, Vladimir Sitnikov wrote:
AFAIK it does wait for the Nexus to release, however, I have no idea if
AFAIK it does wait for the Nexus to release, however, I have no idea if
that means the files are immediately available.
Vladimir
Thanks for confirming, Vladimir. I'll fix the dockerfiles and make
1.17.0 available for voting.
Does the release repository task wait until the repository has been
fully released before returning? If so, I think it should be quite easy
to rearrange the tasks and we can get it into this
Francis>My assumption is that they should be equivalent, but I would love
to get
Francis>some confirmation first as releasing a broken 1.17.0 would cause
more work.
For instance,
I did check the difference between the -shaded.jar (1.15.0) and .jar
(1.16.0) files on nexus yesterday and they seemed to be roughly the same
size, at least much bigger than the .jar files in (1.15.0).
My assumption is that they should be equivalent, but I would love to get
some confirmation
I haven't looked into this in detail yet, but can share details on one of
the questions:
> - Can anyone confirm if the
> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
> avatica-standalone-server-${AVATICA_VERSION}.jar.
> jars are suppose to be equivalent?
>
The Maven built used
Hey Lei,
I've added you as a contributor on Jira.
Francis
On 19/12/2019 5:44 pm, ppx wrote:
Hi:
Following is my Jira account.
Username: Lei Jiang
Full name: Lei Jiang
Sincerely,
Lei
A live meeting is a good idea. Email discussions tend to make people seem more
dogmatic than they really are, because everyone focuses on the 10% of the
argument they disagree with, rather than the 90% they agree with.
I will endeavor to attend.
Julian
> On Dec 19, 2019, at 12:06 PM, Kevin
Sounds good.
> On Dec 18, 2019, at 2:17 PM, Francis Chuang wrote:
>
> Now that Avatica 1.16.0 is just about to be wrapped up, it's time to talk
> about the next release for Avatica-Go, 5.0.0.
>
> Most of the changes are already in place and I will add Avatica-1.16.0 as a
> test target.
>
>
>
> I believe that writing is not great to understand somebody's tone and
> intentions and many things can be misunderstood. Maybe for this and other
> similar issues we should try to hold live discussions.
Shall we try to organize an online meeting?
I think this is a good idea to try. I think
It would be great to have a timestamp type with (timeZone, number) data
content, and also a timestamp type with (number) content and “instant”
semantics, in addition to the current timestamp that has (number) content and
“zoneless” semantics. (I’m avoiding labeling these with SQL type names,
Hi:
Following is my Jira account.
Username: Lei Jiang
Full name: Lei Jiang
Sincerely,
Lei
Glad to have you as the new chair, Stamatis! You have been a mature, helpful
and moderating voice in the community for quite some time. Well deserved.
Francis, thank you for serving as chair. Calcite became better and stronger
under your watch.
I am delighted that we have had 5 chairs in the
Congratulations, Stamatis!
On Thu, Dec 19, 2019 at 9:04 AM Alessandro Solimando <
alessandro.solima...@gmail.com> wrote:
> Congratulations, Stamatis!
>
> Il Gio 19 Dic 2019, 07:16 Enrico Olivelli ha
> scritto:
>
> > Congratulations Stamatis!
> >
> > Enrico
> >
> > Il gio 19 dic 2019, 04:40 Rui
You are right. PostgreSQL's TIMESTAMP WITH TIME ZONE has "Instant"
semantics.
That's the reason that CALCITE-1947 change the type as "TIMESTAMP WITH
LOCAL TIME ZONE"
*Best Regards,*
*Zhenghua Gao*
On Thu, Dec 19, 2019 at 4:17 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
>
Zhenghua>the implementation was similar to PostgreSQL's
PostgreSQL DB stores timestamps similar to "UNIX timestamp" (it uses int8),
and it does that for both "with" and "without" time zone.
In other words, PostgreSQL cannot have "OffsetDateTime" semantics :(
Vladimir
29 matches
Mail list logo
