On Tue, Jul 2, 2013 at 6:52 PM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > "I see that the hive community intends to make hive SQL compliant and is on > that path." . I was not under the general impression that we are on that > path.
Well, whenever we try to decide what the behavior should be, we refer to what SQL standard says. So I think we are certainly on that path, and not going the other way. > Also some SQL operations can not be executed efficiently in map-reduce and > should IMHO not be added to the language. IE if doing the operation means > all data must be shuffled to a single reducer its not something hive should > do. Which SQL feature you are talking about here, that forces single reducer and hence should not be supported? But I agree in general that it does not make sense for hive to support ALL sql features. For example, supporting all the transaction semantics or updating a single row in a table does not make sense. So I don't expect hive to be 100% sql complaint, but when we add new features, we always aim to be as compliant with SQL as possible. I think we should convey this to our users. Using the term HiveQL conveys the wrong idea. But calling it SQL not a lie, considering how much other databases deviate from the standard - http://troels.arvin.dk/db/rdbms/ . See how much deviation is there for example in 'limit clause' or the data types supported (and details of data type support) - http://troels.arvin.dk/db/rdbms/#select-limit-simple . > I do not think hive should be mis-representing itself. Simply put, hive is > NOT SQL complaint we should NOT call the language SQL. I think calling it HIVE-SQL conveys the idea very well. > Doing so would only only lead to confusion for people new to the project. > Imagine you are new to hive: > You read "SQL"in the documentation. > You run an "SQL" standard create table query, it fails. See the above page. Any given SQL "standard" create table query is not guaranteed to work in most of the widely used commercial "SQL" databases.
