Closed gmantele closed 5 years ago
For instance, with the following ADQL query:
SELECT col1, count(col2)
FROM tableA
WHERE col2 > 0
GROUP BY col2
ORDER BY col2 ASC
...PostgreSQL throws the following error message:
ERROR: column "realTableA.col1" must appear in the GROUP BY clause or be used
in an aggregate function
...though no realTableA
was used in the ADQL query. This is quite confusing for the user who is obviously not aware that tableA
is the ADQL name of the table realTableA
.
Issue aborted
The easy solution proposed in the commit 09fac54 generates a parsing failure when a column was referenced using a qualified table name (e.g. "aSchema"."aTable"."aColumn"
). Indeed, in this case, since an alias is automatically set on every table, such column references should be also automatically adapted so that replacing the qualified table name by its automatic alias. Otherwise, the SQL query can not properly run.
Considering the very low gravity of this GitHub issue and the complexity (as well as its possible side effects) of the solution to implement to properly support all cases, it is for the moment more wise to abort the resolution of this issue.
When the execution (in the DB) of an ADQL query fails, the error message returned by TAP is coming from the database with sometimes real database names of the table/column(s). This is particularly the case with PostgreSQL.
In order to avoid that, table and columns used in an ADQL query should be aliased as much as possible. In such case, it seems that the database (again, really observed with PostgreSQL for the moment), the errors reported by the database use the alias (adql_name) instead of the real name (db_name).
However, this small fix will not work on column names used only in a constraint part ; it will work for table names and SELECTed columns....but still, it is an improvment