ADQL-2.1 internal draft

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Wed Jun 10 11:27:56 CEST 2015


Hi Walter,

On Wed, Jun 10, 2015 at 01:39:34AM -0700, Walter Landry wrote:
> > (2) if people do manual unit conversions, there's no way a computer
> > can reliably figure out the new unit, so your metadata is hosed.
> > 
> > To satisfy both cases, it really needs to be a two-arg function.
> 
> Now I am really confused.  If I, as a query writer, want to find all
> stars with mass M < 10*solMass, would I write
> 
>   M < IN_UNIT(10,"solMass")

This would be an error, as 10 is unitless and thus cannot be
converted into a mass.

> or
> 
>   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, or into something like

M*5.0276520864756165e-31

if M were found to be in kg, or

M*5.027652086475616e-10

if M ended up being in Yg.  Yes, that's Yottagram.  Your friendly SI
unit for planetary masses.

IN_UNIT(a, b) means "express a such that it is given in unit b, and
bomb out if a's unit and b are not dimensionally compatible.

> >> 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; due to precedence,
you have to fiddle them in somewhere above factor or below
numericValueExpression, so you'll have to mangle the sql92 grammar
quite a bit.  

If someone bothers to do this (bonus points for avoiding left
recursion) and makes sure we're not allowing any weird expressions
and don't produce suprising precedence, I'll stop bickering.  But
it's actual work, and since I don't really see what's wrong with the
functions, I'm certainly too lazy to do it.

Cheers,

       Markus

(weighed down by a load of about 6 Million Yg upon his chair)



More information about the dal mailing list