Re: Re-opening ISSUE-22 on vendor-specific SQL

> Hm … the names of the columns is already implied in the rest of the
> TriplesMap(s) that are using the query as its logical table. I'd be
> concerned about repeating this information onece more in a new property.
>
>
Yes, I considered this, a couple of thoughts:

* If the usage pattern is to define a SQL query as a re-usable entity then
it makes more sense to me to define the columns on the query. I think of
this like defining a view in the mapping that can be used in many
TriplesMaps. From this perspective I like the idea of centrally defining the
columns on the view rather than trying to reverse engineer it from the way
it is used in various places. If the columns are included with the query
definition then it is analogous to a physical table which has a name and
column names.

* I am looking down the road to general SQL composition. Say two SQL Queries
are joined together. We need to know which column comes from which query.
Perhaps this is tangling up a future concern that is not relevant to the
current spec.



> Devil's advocate: Just try to parse it as SQL 2008; if that fails, it's
> vendor-specific?
>
> A problem I see is that the average mapping author may not be aware of the
> differences between SQL 2008 and the SQL dialect they use. So they would
> have trouble if asked to indicate which queries are vendor specific and
> which are not.
>

Yes, I think that is an entirely valid concern. On the other hand if a SQL
query fails to parse as SQL 2008 it can often just mean that it is invalid.

-David