ADQL: How to handle Unnamed column expressions in SELECT clause

[Stelios Voutsinas]

Dear DAL List,

A similar issue to the GROUP BY email sent out a few days ago, is how to deal with expressions in the SELECT clause of a query that are not aliased and in particular what should be the name of the returned columns.

For example what should a user, or an automated script, expect as the result columns of this query?

     SELECT (ra+dec), -ra FROM alpha_source

I've tested with a few different catalogues and TAP services, as well as different Database Systems and I'm noticing a few different approaches. I'm wondering whether there is a gap here that we should think about (ADQL?, TAP?, VOTable?), as results of such a query may be re-used (i.e. stored in an SQL Server database in our case) and the clients at the moment have no way of knowing what the columns will be named, and if the names will cause problems when re-used. 
Or a user may revisit a VOTable of a query run in the past and may be confused if such columns do not have consistent naming.

Some of the main options are :

* Allow a column with no name

     ra / 2 => ''

* Simple name generator

     ra / 2 => 'COL_1'

* Random name generator

     ra / 2 => 'ahblwwnbtm'

* Reject the query and require an AS

     ra / 2 => AS xyz

* Wrap the expression in quotes

     ra / 2 => "ra / 2"

* Implementation specific naming, i.e. Java object name

     ra / 2 => net.sf.jsqlparser.expression.InverseExpression at 8cae..

We have put together a wiki page with details of the different
approaches with their advantages and disadvantages here : https://github.com/ivoa/cosmopterix/wiki/Unnamed-columns

It would be interesting to hear people's thoughts on this and see whether this is something that needs to be standardized, and if so how and where. 

Cheers,

Stelios Voutsinas
Software Developer
WFAU, Institute for Astronomy
University of Edinburgh