ADQL-2.1 internal draft

[Walter Landry]

Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> Dear DAL,
> 
> On Wed, Jun 10, 2015 at 01:59:00PM -0700, Walter Landry wrote:
>> Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>> > On Wed, Jun 10, 2015 at 01:39:34AM -0700, Walter Landry wrote:
>> >>   IN_UNIT(M,"solMass") < 10
>> > 
>> > That would work if M is a mass.  The translation layer would turn
>> > this into 
>> > 
>> > M
>> > 
>> > if it worked out that M is in solar masses
>> 
>> Isn't this undecidable when you use a function like pow(x,y)?  You
>> have to actually run the query and look at the results before you can
>> verify the units.
> 
> My original proposal was to *require* in_unit, but require sane
> behaviour only on simple column references. Working on full
> expressions would be not be required, but implementors would be free
> to try it.  Implementations may or will have to refuse many
> constructs anyway; for instance, stuff like in_unit(parallax+magV,
> "mas") must be rejected (I admit the current error message in
> http://dc.zah.uni-heidelberg.de/__system__/adql/query/form?__nevow_form__=genForm&query=select%20in_unit(pmra%2Bepde%2C%20'mas%2Fyr')%20from%20fk6.fk6join&_TIMEOUT=5&_FORMAT=HTML&submit=Go
> needs work, but I guess you get the idea).
> 
> pow(x,y) is an example that simply doesn't allow unit annotation.  In
> our data model (i.e., VOTable), units are given globally per column,
> and thus that expression cannot be reliably given a unit.  That's not
> a probleme specific to in_unit; as TAP engines should give the units
> in their VOTable output, they should have unit annotations anyway.
> If they have that, in_unit isn't terribly expensive.

I am uncomfortable with this.  To implement IN_UNIT, I have to

1) Parse the query.
2) Query the database for column information.
3) Rewrite the query, including scaling for IN_UNIT expressions.
4) Run the query.

I do not like this interruption that happens in the middle.  It would
complicate my parser a fair amount.  I can no longer rewrite the query
as I am parsing.

In general, it feels like a little too much magic for the back end.

>> >> >> 5) Why are we making new function names BIT_AND, BIT_OR, etc?  Why not
>> >> >>    just use the operators?  It is what everyone but Oracle and
>> >> >>    Informix implement, and they use different names anyway.
>> >> > 
>> >> > ...but operators are harder to parse (precedence!  Left-recursive
>> >> > rules!), and it's easier for a machine to go from prefix notation to
>> >> > infix than the other way round.  I'm all for functions.
>> >> 
>> >> We have to parse the operators anyway.  And it is really not
>> >> that hard.
>> > 
>> > It's not hard, but it's a bunch of extra rules;
>> 
>> I am confused.  The spec says that we have to parse operators.  Are
>> you suggesting modifying the proposal to get rid of the operators?
>> That would be gratuitously incompatible with MS SQL, Postgres, MySQL,
>> and SQLite.
> 
> But mapping functions to operators is trivial, the other way round
> requires actual parsing and grammar rules.

Ok.  As long as we have only one way of doing it.  So we should change
the proposal.

Cheers,
Walter Landry