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
SELECT isbn, title, price
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
"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.
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 <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 2, 2013 at 6:52 PM, Edward Capriolo <[EMAIL PROTECTED]>
> > "I see that the hive community intends to make hive SQL compliant and is
> > 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
> > 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
> > 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
> > 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"