What is in a name? :) "Which SQL feature you are talking about here, that forces single reducer and hence should not be supported?"
Joining on anything besides = comes to mind Pretty sure the query mentioned here will not work (without being re-written) http://en.wikipedia.org/wiki/SQL SELECT isbn, title, price FROM Book WHERE price < (SELECT AVG(price) FROM Book) ORDER BY title; "Using the term HiveQL conveys the wrong idea" I disagree. HiveQL is HiveQL. The only idea it can convey is itself. Our wiki describes this perfectly https://cwiki.apache.org/confluence/display/Hive/Home "Hive defines a simple SQL-like query language, called QL, that enables users familiar with SQL to query the data. " Hive-SQL looks like it is trying to convey the idea that hive supports extensions like T-SQL http://en.wikipedia.org/wiki/Transact-SQL or PL/SQL. http://www.oracle.com/technetwork/database/features/plsql/index.html. T-SQL and PLSQL are both adding extensions on top of a "mostly" SQL compliant database. Instead we would be using Hive-SQL to sugar coat/hide the fact that Hive is not SQL complaint (and not even close IMHO). Lessons from my mother. "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." You can't be half a saint. "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) -" If all your friends jumped off a bridge would you do it? If I had to suggest another name for HiveQL. I might call it Almost-SQL++. On Tue, Jul 2, 2013 at 10:19 PM, Thejas Nair <the...@hortonworks.com> wrote: > 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. >
