"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.
Someone once told me that supporting full SQL will result in roughly 4 times the parser and planner code. For me that is not a huge win. 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. I do not think hive should be mis-representing itself. Simply put, hive is NOT SQL complaint we should NOT call the language SQL. 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. You struggle creating the table, finally you get it created, and then run an SQL complaint correlated sub query, and that fails. You say to you self "What a fricken piece of crud this hive is! they claim it's SQL but it's not. What else are they lying to me about?" On Tue, Jul 2, 2013 at 9:28 PM, Thejas Nair <the...@hortonworks.com> wrote: > I see that the hive community intends to make hive SQL compliant and > is on that path. Just like other databases, it has some extensions to > SQL, and there are some standard features it does not support. > > SQL is also one of the strong selling points of hive. But using the > term HiveQL, I think conveys this idea very poorly. > I propose deprecating use of the term HiveQL and using the term > Hive-SQL or just SQL depending on the context, in hive documentation. > > What does the hive community think ? > > Thanks, > Thejas >
