if the alias is not delimited in ADQL.

This commit fixes the GitHub issue #56

this table is declared with an alias. Instead, the table alias must be used.

Note: This problem occurred only when ADQLParser was used with a DBChecker.

This commit fixes the GitHub issue #53

See the test case TestDBChecker.testClauseADQLWithNameNull() for more details.

since the commit 8e2fa9ff.

(https://github.com/gmantele/taplib/commit/7a70c6038cef460ab169682bed391bb5ae1de1e9)

It was not possible to use a GROUP BY with a qualified column name.
So finally, now, a GROUP BY is a ClauseADQL<ADQLColumn> instead of
a ClauseADQL<ColumnReference>. Indeed, according to the ADQL's BNF,
GROUP BY items are only columns as they would appear in the SELECT
clause (i.e. qualified or not, delimited or not). On the other
hand an ORDER BY accepts ONLY column index or non-qualified column
name/alias.

The class ColumnReference is kept for backward compatibility (or in
case the next version of the ADQL grammar make items of GROUP BY and
ORDER BY of the same type: index or qualified column). Besides, this
class is still inherited for the ORDER BY clause items
(see adql.query.ADQLOrder).

This error has been raised on the issue #32 by Zarquan.

sub-query. Without this information, it was impossible to resolve columns makingreference to sub-queries of the clause FROM. See the JUnit test case for a
concrete example.
(error raised by Hendrik Heinl - ARI/GAVO)

in DBType.DBDatatype (for UNKNOWN and UNKNOWN_NUMERIC). This reset is performed
after each JUnit setting a special custom value (otherwise it prevents other
JUnit to run correctly)

This is easily possible for concatenations, string constants and User Defined
Functions having a FunctionDef. A new special datatype was needed for
numeric functions and operations: UNKNOWN_NUMERIC. This special type
can not be set with FunctionDef.parse(...) and it behaves exactly like the type
UNKNOWN, except that DBType.isNumeric() returns true (as .isUnknown()).
Thus, while writing the metadata of a result in TAP, nothing changes:
an UNKNOWN_NUMERIC type will be processed similarly as an UNKNOWN type:
to use the type returned from the database ResultSet or to set VARCHAR.
(no modification of TAP was needed for that)

Functions whose some parameters are another function were not correctly
identified: since the inner functions were not yet identified, their type
was UNKNOWN and so it makes the identification of the parent function
much easier since an UNKNOWN parameter is not checked. But, it was a
problem if the parameter occurs to be finally of the wrong type.

types. The notion of "unknown type" is different in function of the target
object:
  - a DBType and a FunctionDef have an unknown type if their function
    isUnknown() returns true. In such case, the other functions such as
	isNumeric/String/Geometry() will return false.
  - an ADQLOperand (e.g. ADQLColumn) does NOT have a isUnknown() function.
    But if the type of the operand is unknown, its functions isNumeric(),
	isString() and isGeometry() must ALL return true. Otherwise, just one of
	these functions can return true.

when in a table definition (extension of DBTable) no schema is
specified, it was possible to prefix the table name by a fake
schema name ; it was checked at all:
e.g. "SELECT * FROM no_schema.foo".
This is no longer possible: if no schema is specified, no schema
must be used in an ADQL query. But if one is specified, the schema
prefix is optional.

1/ Bad parsing of UDF's parameter type or return type. Database types whose the
name has a space (e.g. 'double precision') were not accepted. These type names
should be accepted according to TAPRegExt.
2/ An error message thrown by the DBChecker has been modified for the cases
the type of a parameter is unknown. Before the returned type was NUMERIC. Now,
it will be 'param' followed by the parameter index (e.g. 'param1').

(merge with branch 'unknownFctType')

[ADQL,TAP] Add STC-S and UDFs support in the ADQL parser. Now, it is possible to provide a list of allowed UDFs, regions and coordinate systems. The ServiceConnection of TAP is now able to provide these lists and to propagate them to the ADQLExecutor. UDFs and allowed regions are now listed automatically in the /capabilities resource of TAP. The type 'geometry' is now fully supported in ADQL. That's why the new function 'isGeometry()' has been added to all ADQLOperand extensions. Now the DBChecker is also able to check roughly types of columns and UDFs (unknown when parsing syntactically a query). The syntax of STC-S regions (expressed in the REGION function) are now checked by DBChecker. However, for the moment, geometries are not serialized in STC-S in the output....but it should be possible in some way in the next commit(s).