[
https://issues.apache.org/jira/browse/IMPALA-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861195#comment-16861195
]
Tim Armstrong commented on IMPALA-8367:
---------------------------------------
I'm not going to dig in on this one - the stakes are pretty low. I'll explain
my reasoning then move on :).
Generally what I've seen in programming language design is that it's better to
make the language consistent and predictable instead of trying to predict
user's intent with special cases. It's tempting to try to help out users in
common cases, but if it's too pervasive then users can't reason about what a
particular bit of code will do. For me, Python vs Perl is a pretty good example
of this. Perl goes to great lengths to be convenient and allow shortcuts for
common code patterns, but it's just filled with special cases. Python sometimes
is more verbose, but it's way more consistent.
In this specific case, it's violating the invariant that an expression should
return the same result if the input is a constant vs a variable that has the
same value. This is pretty fundamental and people use it all the time when
writing or refactoring code. I pretty much agree that users *probably* aren't
going to manually write a query with an invalid format and expect it to pass.
But it's really hard to predict what users will do - they're creative and we've
been wrong many times before. A lot of weird stuff comes up with
programmatically-generated SQL, for example. Or with people iteratively
refactoring a big query.
I think probably we should generate warnings for cases like this where the
construct is questionable but has a valid interpretation, but I think it's
marginal whether it's worth the effort to change it right now compared to other
things. So I'm fine with closing it as "wont fix" or "later".
> from_unixtime Bad date/time conversion format: u on NULL value
> --------------------------------------------------------------
>
> Key: IMPALA-8367
> URL: https://issues.apache.org/jira/browse/IMPALA-8367
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 2.11.0
> Environment: impalad version 2.11.0-cdh5.14.2 RELEASE (build
> ed85dce709da9557aeb28be89e8044947708876c) Built on Tue Mar 27 13:39:48 PDT
> 2018
> Reporter: Sergio Leoni
> Priority: Minor
> Labels: newbie, ramp-up
>
> The function
> {code:sql}
> from_unixtime(bigint unixtime[, string format]) {code}
> output error if the value of unixtime is NULL and format is 'u'.
>
> This doesn't work:
> {code:sql}
> SELECT FROM_UNIXTIME(NULL, 'u')
> {code}
> {noformat}
> Bad date/time conversion format: u{noformat}
>
> This works:
> {code:sql}
> SELECT FROM_UNIXTIME(NULL, 'yyyy-MM-dd')
> {code}
> {noformat}
> |from_unixtime(null, 'yyyy-mm-dd')|
> |---------------------------------|
> | NULL |
> |---------------------------------|{noformat}
>
> I haven't checked all the possible combinations.
> Other software like Hive handles this correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
