GitHub user yhuai opened a pull request:

    https://github.com/apache/spark/pull/6914

    [SPARK-8420] [SQL] Fix comparision of timestamps/dates with strings 
(branch-1.4)

    This is branch 1.4 backport of https://github.com/apache/spark/pull/6888.
    
    Below is the original description.
    
    In earlier versions of Spark SQL we casted `TimestampType` and `DataType` 
to `StringType` when it was involved in a binary comparison with a 
`StringType`.  This allowed comparing a timestamp with a partial date as a user 
would expect.
     - `time > "2014-06-10"`
     - `time > "2014"`
    
    In 1.4.0 we tried to cast the String instead into a Timestamp.  However, 
since partial dates are not a valid complete timestamp this results in `null` 
which results in the tuple being filtered.
    
    This PR restores the earlier behavior.  Note that we still special case 
equality so that these comparisons are not affected by not printing zeros for 
subsecond precision.
    
    Author: Michael Armbrust <[email protected]>
    
    Closes #6888 from marmbrus/timeCompareString and squashes the following 
commits:
    
    bdef29c [Michael Armbrust] test partial date
    1f09adf [Michael Armbrust] special handling of equality
    1172c60 [Michael Armbrust] more test fixing
    4dfc412 [Michael Armbrust] fix tests
    aaa9508 [Michael Armbrust] newline
    04d908f [Michael Armbrust] [SPARK-8420][SQL] Fix comparision of 
timestamps/dates with strings
    
    Conflicts:
        
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/HiveTypeCoercion.scala
        
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/predicates.scala

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/yhuai/spark timeCompareString-1.4

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/spark/pull/6914.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #6914
    
----
commit e6e15d68ae7870e9251da470bc71a8a6a37b733e
Author: Michael Armbrust <[email protected]>
Date:   2015-06-19T23:54:51Z

    [SPARK-8420] [SQL] Fix comparision of timestamps/dates with strings
    
    In earlier versions of Spark SQL we casted `TimestampType` and `DataType` 
to `StringType` when it was involved in a binary comparison with a 
`StringType`.  This allowed comparing a timestamp with a partial date as a user 
would expect.
     - `time > "2014-06-10"`
     - `time > "2014"`
    
    In 1.4.0 we tried to cast the String instead into a Timestamp.  However, 
since partial dates are not a valid complete timestamp this results in `null` 
which results in the tuple being filtered.
    
    This PR restores the earlier behavior.  Note that we still special case 
equality so that these comparisons are not affected by not printing zeros for 
subsecond precision.
    
    Author: Michael Armbrust <[email protected]>
    
    Closes #6888 from marmbrus/timeCompareString and squashes the following 
commits:
    
    bdef29c [Michael Armbrust] test partial date
    1f09adf [Michael Armbrust] special handling of equality
    1172c60 [Michael Armbrust] more test fixing
    4dfc412 [Michael Armbrust] fix tests
    aaa9508 [Michael Armbrust] newline
    04d908f [Michael Armbrust] [SPARK-8420][SQL] Fix comparision of 
timestamps/dates with strings
    
    Conflicts:
        
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/HiveTypeCoercion.scala
        
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/predicates.scala

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to