srowen commented on a change in pull request #25981: [SPARK-28420][SQL] Support
the `INTERVAL` type in `date_part()`
URL: https://github.com/apache/spark/pull/25981#discussion_r332578044
##########
File path:
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/datetimeExpressions.scala
##########
@@ -2067,6 +2082,10 @@ object DatePart {
224
> SELECT _FUNC_('SECONDS', timestamp'2019-10-01 00:00:01.000001');
1.000001
+ > SELECT _FUNC_('days', interval 1 year 10 months 5 days);
Review comment:
> The entire interval's length is returned for `EPOCH` only, and components
for other `field` values.
Hm, but then back to the original question; why is the answer not 30 below?
```
SELECT _FUNC_('seconds', interval 30 seconds 1 milliseconds 1 microseconds);
30.001001
```
I'm not concerned necessarily about matching PostgreSQL, but am concerned
about internal consistency. Unless I'm really missing something, these two
examples here seem to have different semantics. I understand if you mean it's
the natural way to implement this given the representation, but, I'm not sure
that makes it right?
I think the discussion of `PERIOD` is separate. Here the question is the use
case for `date_part` on an interval. I'm sort of struggling to think of when
that's useful, though I accept it exists in other DBs. Your example doesn't
show using `date_part`. I can imagine wanting to render an interval in given
units -- what is the length of this whole interval in seconds? -- but that's
not what this does, nor what the function name seems to imply.
That's why I'm questioning supporting this at all.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
