Is UNQL Really meant to be a superset of SQL?

[Roland Bouman]

Hi!

I read this interview with Richard Hipp at http://www.infoq.com/news/2011/08/UnQL,
and it reads:

"The data manipulation and query language of UnQL is a functional
superset of SQL, so UnQL can, in theory, also be used to access legacy
SQL database engines."

I was wondering how serious I should take that. If it's true, it seems
that the production for the select-core production is not correct,
because it does not allow a list of expressions, but only one optional
expression.

I am assuming this is intentional, is that correct?

I have been thinking a bit about why the production was designed that
way, and I think it is to ensure that a select-core (and by extension
select-stmt) will return a collection of documents. That is: the UnQL
analogon of a row is a document, since SQL select statements return a
set of rows, so must an UnQL statement return a set or rather
collection of documents. But at the same timeUnQL cannot be a superset
of SQL unless it allows a list of expressions in the select list.

So the question is, should UnQL be a superset of SQL? If not, it is
best to completely forget all about it since this idea could burden
further language design.

I'm also wondering how bad it would really be if UNQL would allow a
list of expressions in the select list. If you want to preserve the
property that a UnSQL select returns a collection of documents, then
it seems to me a list of documents could always be wrapped into a new
document, either by storing them in an array or a dictionary (object).
(In that latter case, a given alias could be used as key, and if the
alias is ommitted the ordinal position could be used as key)

As always, I'm very curious about other people's opinion on these
matters.

Thanks in advance and kind regards,

Roland.