What's new?

The list of all modifications done recently on the library.

v1.5 - 20th March 2019

v1.4 - 26th February 2018

  • keep the same case for undelimited column names ...

    When translating into SQL, if a column was declared with no alias and was not delimited (i.e. between double quotes), the translator set an alias with the column name...but in the same case. Depending on the used database and its configuration, the different case between the alias and its references would throw an error.

    For instance, the following ADQL query:

    SELECT t.*
			FROM (SELECT (ra+ra_error) AS x,
						 pmra AS "ProperMotion",
						 (dec+dec_error) AS Y
					FROM mytable) AS t

    triggered the following error with PostgreSQL:

    Caused by a org.postgresql.util.PSQLException at  [...]
			ERROR: column t.Y does not exist

    because its translation in SQL was:

    SELECT "t"."x", "t"."ProperMotion", "t"."Y"
			FROM (SELECT ("public"."mytable"."ra"+"public"."mytable"."ra_error") AS x,
						 "public"."mytable"."pmra" AS "ProperMotion",
						 ("public"."mytable"."dec"+"public"."mytable"."dec_error") AS Y
					FROM "public"."mytable") AS "t"

    To avoid this error, automatic aliases are always delimited and written in lower-case. Which would now look like below: 

    SELECT "t"."x" AS "x", "t"."ProperMotion" AS "ProperMotion", "t"."y" AS "y"
			FROM (SELECT ("public"."table2"."ra"+"public"."table2"."ra_error") AS "x",
						 "public"."table2"."pmra" AS "ProperMotion",
						 ("public"."table2"."dec"+"public"."table2"."dec_error") AS "y"
					FROM "public"."table2") AS "t"

    See on Gi tHub

  • Multiple space characters between the tokens ORDER/GROUP and BY ...

    Before this correction, ORDER BY and GROUP BY had to be written with only one space (i.e. ' '). Now, it is perfectly allowed to write more than one space (and even any space character such as a tab or a new line) between ORDER/GROUP and BY.

    See on GitHub

  • Fix automatic name of some operands (e.g. +, -, ...) ...

    The idea is to get rid of special characters such as '-', '+' , '(', ... in the columns name of the output table.

    See on GitHub

  • Infinite loop when wrapping items matched with SimpleReplaceHandler ...

    This infinite loop occured only when the replacement object is just a wrapping of the matching object ; after replacement, the new object was inspected for matching objects.

    Example: infinite loop if we want to wrap all foo(...) functions with the function ROUND in the following query: 

    SELECT foo(foo(123)) FROM myTable

    Expected result:

    SELECT ROUND(foo(ROUND(foo(123)))) FROM myTable

    But generated result was:

    SELECT ROUND(ROUND(ROUND(......foo(foo(123))))) FROM myTable

    See on GitHub

  • Incomplete handling of delimited aliases ...

    Between double quotes an alias could contain any character, but it seems that the dot (.) was interpreted anyway (as table/column separator) before this fix.

    See on GitHub

  • Finishing a query with a comment triggered an error ...

    See on GitHub

  • The function CENTROID returns a geometry not a numeric ...

    In addition to this bug correction, a translation of CENTROID using PgSphere has been implemented.

    See on GitHub: 6106390... and 3306dec...

  • Strange tree generation for NATURAL JOINs ...

    The "normal" JOIN (e.g. A JOIN B ON A.id = B.id JOIN C ON B.id = C.id) is correctly interpreted (e.g. ( (A JOIN B ON A.id = B.id) JOIN C ON B.id = C.id )). But with a NATURAL JOIN, an ADQL instruction like A NATURAL JOIN B NATURAL JOIN C gives ( A NATURAL JOIN (B NATURAL JOIN C) ) instead of ( (A NATURAL JOIN B) NATURAL JOIN C ).

    See on GitHub

  • For PSQL translator, cast numeric parameters of mathematical functions ...

    DOUBLE and REAL parameters of mathematical functions must be casted into NUMERIC. Otherwise Postgres rejects the query.

    See on GitHub

  • Escape single and double quotes as expected ...

    A string constant in ADQL is enclosed between single quotes. But is is also possible to have single quotes being part of the string constant, by doubling these single quotes, as show below: 

    SELECT 'foo''s bar' FROM myTable

    The result of a such query should return the string foo's bar. But the library did not do that until this commit.

    The same bug but about double quotes is also fixed.

    See 9e8f8e7 for single quotes and 239c717 for double quotes

  • Fix the possibility to enable the DEBUG mode in the parser. ...

    Since the version 1.3, the DEBUG mode was disabled by default, but it was surprisingly impossible to enable it again. Now, the DEBUG mode is still disabled by default as promessed in version 1.3, but it can be enabled using the function setDebug(boolean).

    See on GitHub

  • No metadata set for a sub-query ...

    Due to this omission, it was impossible to make any reference to any column returned by this sub-query in the parent query. (see the JUnit test for a concrete example)

    See on GitHub

  • The keyword AS for SELECT item aliases is optional ...

    Before this correction the alias was optional but not the keyword AS. Now, if the alias is provided, it may be specified with OR without AS.

    See on GitHub

  • Recursive replacement with SimpleReplaceHandler ...

    For instance: if all mathematical functions must be replaced by a dumb UDF named 'foo' in the ADQL query: 

    SELECT sqrt(abs(81)) FROM myTable

    the result should be:

    SELECT foo(foo(81)) FROM myTable

    but before this correction it was:

    SELECT foo(abs(81)) FROM myTable

    See on GitHub

  • NullPointerException for math functions ...

    Some functions like PI() and RAND() were affected by this bug.

    See on GitHub

  • Incorrect or incomplete translation from ADQL to SQL ...
    • The character ' was not escaped. Now, all occurences of ' are replaced by '' in the SQL translation.

      See on GitHub

    • In PostgreSQL: numerical parameters of mathematical functions (e.g. LOG(), LOG10()) were not casted into NUMERIC. Without this CAST, PostgreSQL rejects quite often the query.

      See on GitHub

  • ORDER BY and GROUP BY ...

    a. In ORDER BY, GROUP BY and USING only regular and delimited identifiers are accepted, not qualified column names.

    For instance:

    SELECT table.column_name
			FROM table
			ORDER BY table.column_name

    is wrong. We should instead write:

    SELECT table.column_name
			FROM table
			ORDER BY column_name

    or

    SELECT table.column_name AS mycol
			FROM table
			ORDER BY mycol

    See on GitHub

    b. No SELECT item index in GROUP BY

    According to the ADQL grammar, a GROUP BY item must be a column name or an alias. Before this correction, the index of a SELECT item could have been provided as it is possible for ORDER BY. This is no longer possible. The ADQL parser will accept only column name or alias in a GROUP BY clause.

    See on GitHub

    c. But a qualified identifier in GROUP BY is allowed

    For instance, the following ADQL query is correct:

    SELECT *
			FROM table
			GROUP BY table.oid

    See on GitHub: 7a70c60... and 8e2fa9f...

  • Fake schema name ...

    Before this correction, it was possible to write the following ADQL query: 

    SELECT *
			FROM fakeSchema.myTable

    ...although the table myTable was defined in the tables metadata (e.g. TAP_SCHEMA) with no schema. Now, it is no longer possible: if a table is defined no schema as myTable it MUST NOT be prefixed by any schema name. But as before, if a table is defined in the tables metadata (e.g. TAP_SCHEMA) with a schema, this latter MAY prefix the table name in an ADQL query.

    See on GitHub

  • Functions inside functions ...

    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.

    See on GitHub

  • Declaration of UDF parameters ...

    Unknown datatypes in the declaration of User Defined Functions were reported with a confusing error message. Now, the error message specifies such datatype as param<i> (<i> being the index of the parameter).

    Besides types having space like double precision were not supported: they throw an "unknown datatype" error. Now, more database datatypes and in particular double precision and character varying are supported.

    See on GitHub

  • "aSchema"."aTable.WithADot" ...

    This qualified table name was interpreted similarly as the table "aSchema"."WithADot", or in other words, the table WithADot inside the schema aSchema. Now, it will really be interpreted as a table named aTable.WithADot inside the schema aSchema.

    See on GitHub

v1.3 - 07th May 2015

This sub-version fixes also few (but quite important) bugs and adds a better support for STC-S expressions and UDFs.

v1.2 - 15th April 2014

This sub-version is just a correction of several bugs often encountered. Here are the major bugs fixed (the list is not exhaustive):

v1.1 - 15th June 2012