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 interval type, and don't support storing that. That gets me thinking in reality storing interval type is not that useful. Do we really need to do this? One of the worst things we can do as a community is to introduce features that are almost never used, but at the same time have high internal complexity for maintenance. On Fri, Jan 10, 2020 at 10:45 AM, Dongjoon Hyun < dongjoon.h...@gmail.com > wrote: > > Thank you for clarification. > > > Bests, > Dongjoon. > > On Fri, Jan 10, 2020 at 10:07 AM Kent Yao < yaooqinn@ qq. com ( > yaooq...@qq.com ) > 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` -> CalenderIntervalType support in the parser >> >> >> Thanks >> >> >> *Kent Yao* >> Data Science Center, Hangzhou Research Institute, Netease Corp. >> PHONE: (86) 186-5715-3499 >> EMAIL: hzyaoqin@ corp. netease. com ( hzyao...@corp.netease.com ) >> >> >> On 01/11/2020 01:57 ， Dongjoon Hyun<dongjoon. hyun@ gmail. com> ( >> dongjoon.h...@gmail.com ) wrote： >> >>> 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 < yaooqinn@ qq. com ( >>> yaooq...@qq.com ) > wrote: >>> >>> >>>> Hi, Devs >>>> >>>> I’d like to propose to add two new interval types which are year-month and >>>> >>>> day-time intervals for better ANSI support and future improvements. We >>>> will >>>> keep the current CalenderIntervalType but mark it as deprecated until we >>>> find the right time to remove it completely. The backward compatibility of >>>> >>>> the old interval type usages in 2.4 will be guaranteed. >>>> >>>> Here is the design doc: >>>> >>>> [SPIP] Support Year-Month and Day-Time Intervals - >>>> https:/ / docs. google. com/ document/ d/ >>>> 1JNRzcBk4hcm7k2cOXSG1A9U9QM2iNGQzBSXZzScUwAU/ >>>> edit?usp=sharing ( >>>> https://docs.google.com/document/d/1JNRzcBk4hcm7k2cOXSG1A9U9QM2iNGQzBSXZzScUwAU/edit?usp=sharing >>>> ) >>>> >>>> All comments are welcome! >>>> >>>> Thanks, >>>> >>>> Kent Yao >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from: http:/ / apache-spark-developers-list. 1001551. n3. nabble. com/ >>>> ( http://apache-spark-developers-list.1001551.n3.nabble.com/ ) >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe e-mail: dev-unsubscribe@ spark. apache. org ( >>>> dev-unsubscr...@spark.apache.org ) >>> >>> >>> >> >> > >
