The proposal makes sense to me. If we are not going to make interval type
ANSI-compliant in this release, we should not expose it widely.
Thanks for driving it, Kent!
On Fri, Jan 17, 2020 at 10:52 AM Dr. Kent Yao wrote:
> Following ANSI might be a good option but also a serious user behavior
>
Following ANSI might be a good option but also a serious user behavior change
to introduce two different interval types, so I also agree with Reynold to
follow what we have done since version 1.5.0, just like Snowflake and
Redshift.
Perhaps, we can make some efforts for the current interval type t
Introducing a new data type has high overhead, both in terms of internal
complexity and users' cognitive load. Introducing two data types would have
even higher overhead.
I looked quickly and looks like both Redshift and Snowflake, two of the most
recent SQL analytics successes, have only one i
Thank you for clarification.
Bests,
Dongjoon.
On Fri, Jan 10, 2020 at 10:07 AM Kent Yao wrote:
> Hi Dongjoon,
>
> Yes, As we want make CalenderIntervalType deprecated and so far, we just
> find
> 1. The make_interval function that produces legacy CalenderIntervalType
> values,
> 2. `interval` -
Hi Dongjoon,Yes, As we want make CalenderIntervalType deprecated and so far, we just find1. The make_interval function that produces legacy CalenderIntervalType values, 2. `interval` -> CalenderIntervalType support in the parserThanks
Hi, Kent.
Thank you for the proposal.
Does your proposal need to revert something from the master branch?
I'm just asking because it's not clear in the proposal document.
Bests,
Dongjoon.
On Fri, Jan 10, 2020 at 5:31 AM Dr. Kent Yao wrote:
> Hi, Devs
>
> I’d like to propose to add two new int
