ADQL: How to handle Unnamed column expressions in SELECT clause

[Mark Taylor]

Stelios,

my feeling (unless somebody persuades me differently) is:
don't standardise this.

In some cases you don't care about the name (e.g. if you're submitting
the query programmatically and you just need to know what order the
columns will be output in).
In many cases you do care about the name: in that case use AS.

Often I submit a query without an AS (because I don't remember this
issue), get back some kind of gobbledegook as column name,
and then resubmit the query with an AS if I need to have column
names different from whatever the service happens to generate in that case.
It works OK.

The alternative of getting standards text written to legislate what
happens for unaliased columns, and then reading/understanding/remembering
that standards text so you can leave out AS clauses sometimes
doesn't look to me like effort well spent.

So I'd say no action required here.

Mark

On Fri, 6 May 2016, Stelios Voutsinas wrote:

> 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

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/