[ https://issues.apache.org/jira/browse/HIVE-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769931#comment-13769931 ]
Sergey Shelukhin commented on HIVE-5304: ---------------------------------------- Actually, all names - I see show indexes order also changes in some queries, etc. > JDO and SQL filters can both return different results for string compares > depending on underlying datastore > ----------------------------------------------------------------------------------------------------------- > > Key: HIVE-5304 > URL: https://issues.apache.org/jira/browse/HIVE-5304 > Project: Hive > Issue Type: Bug > Components: Metastore > Reporter: Sergey Shelukhin > > Hive uses JDOQL filters to optimize partition retrieval; recently direct SQL > was added to optimize it further. Both of these methods may end up pushing > StringCol op 'SomeString' to underlying SQL datastore. Many paths also pushes > order by-s, although these are not as problematic. > The problem is that different datastores handle string compares differently. > While testing on Postgres, I see that results in different things, from > innocent like order changes in "show partitions", to more serious like > {code} > alter table ptestfilter drop partition (c>='US', d<='2') > {code} > in drop_partitions_filter.q - in Derby, with which the .q.out file was > generated, it drops "c=Uganda/d=2"; this also passes on MySQL (I ran tests > with autocreated db); on Postgres with a db from the script it doesn't. > Looks like we need to enforce collation in partition names and > part_key_values-es; both in the create scripts, as well as during autocreate > (via package.jdo?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira