On Tue, Jul 2, 2013 at 6:52 PM, Edward Capriolo <[EMAIL PROTECTED]> 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
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
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) -
> 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"