ADQL-2.1 Working Draft available on the repo

[Markus Demleitner]

Dear DAL,

On Mon, May 09, 2016 at 03:59:09PM +0200, Ger van Diepen wrote:
[function names are reserved words in ADQL]
> Thanks for your explanation. 
> I understand, although I think an error message like "name 'abc' is not
> defined" (as Python will give) will be just as clear. 
> 
> But note it is not possible to make every function a reserved ADQL
> keyword, certainly not for UDFs and (to assure backward compatibility)
> for functions added at a later stage. I certainly hope that parsers
> won't rely on function names being reserved keywords. 

I essentially agree on both counts -- I'd even say that if the parser
could work out that something must be a function name (and I believe
in an expresion like 5*SING(x) it could) and finds that it doesn't
know it, a message like "Undefined function: SING" might even be
clearer.

[I can't bring myself to object to adding reserved words in minor
releases, though, although I think I should]

I have to say I am not sure why the SQL designers went the way of
reserving the names of their functions, but they did, long before
ADQL was discussed.  Now, SQL92, which ADQL was derived from, has a
lot less functions than ADQL does (for instance, there are no
transcendental functions at all), so a point could have been made
that ADQL with its much richer function set should have deviated from
the SQL92 practice of reserving function names.

Given the design goal be as compatible as possible to SQL92, this
would have meant that there are certain functions with reserved names
(those from SQL92) and others with "free" names that are not part of
the grammar (with the side effect that you wouldn't fix their
parameter signatures in the grammar).

Me, I'd probably have advocated to go that way back then anyway,
mainly because of the aesthetic judgement that it's more in line with
what other modern languages do (but then other modern languages don't
have delimited identifiers that let you use reserved names as
identifiers after all).

In 2016 doing that would require a change in ADQL. I'd be reluctant
to do that, since I don't see a strong technical reason (as in: we
could do something we can't already).  The thing with breaking
working queries when you introduce new reserved names is something
I'm not quite at piece with yet, either.  And as long as we have the
function names in the grammar, I believe we really have to reserve
them, too.

Cheers,

       Markus