DSQL bugs

SF #1408079 The parser was not validating string literal markers.

fixed by C. Valderrama

~ ~ ~

Not registered The engine would fail to parse the SQL ROLE keyword properly.

fixed by C. Valderrama

~ ~ ~

Not registered EXECUTE PROCEDURE did not check SQL permissions at the prepare stage.

fixed by D. Yemanov

~ ~ ~

SF #217042 Weird SQL constructions are not always properly validated.

Partly fixed by C. Valderrama

~ ~ ~

SF #1108909 View could be created without rights on a table name like a b

fixed by C. Valderrama

~ ~ ~

SF #512975 Clear embedded spaces and CR+LF before DEFAULT clauses when storing them in system tables.

Implemented by C. Valderrama

SF #910423 Anomaly with ALTER TABLE altering a column's type to VARCHAR, when determining valid length of the string.

 SQL> CREATE TABLE tab ( i INTEGER );
 SQL> INSERT INTO tab VALUES (2000000000);
 SQL> COMMIT;
 SQL> ALTER TABLE tab ALTER i TYPE VARCHAR(5);
 Statement failed, SQLCODE = -607
 unsuccessful metadata update
-New size specified for column I must be at least 11 characters. i.e., it would need potentially 10 characters for the numerals and one for the negative sign.

 SQL> ALTER TABLE tab ALTER i TYPE VARCHAR(9);

This command should fail with the same error, but it did not, which could later lead to unreadable data:

SQL> SELECT * FROM tab;
I
=========
Statement failed, SQLCODE = -413
conversion error from string "2000000000"

fixed by C. Valderrama

~ ~ ~

Not registered There were some rounding problems in date/time arithmetic.

fixed by N. Samofatov

~ ~ ~

Not registered Line numbers in DSQL parser were being miscounted when multi-line literals and identifiers were used.

fixed by N. Samofatov

~ ~ ~

SF #784121 Some expressions in outer join conditions were causing problems.

fixed by C. Valderrama

~ ~ ~

Not registered There were some dialect- specific arithmetic bugs:

Dialect 1

1. '1.5' / '0.5' did not work
2. avg ('1.5') did not work
3. 5 * '1.5' produced an INT result instead of DOUBLE PRECISION
4. sum ('1.5') produced a NUMERIC(15, 2) result instead of DOUBLE PRECISION
5. - '1.5' did not work

Dialect 3

• '1.5' * '0.5' and '1.5' / '0.5' were not forbidden, but they should have been.

fixed by D. Yemanov

~ ~ ~

SF #1250150 There was a situation where a procedure could not be dropped.

fixed by V. Horsun

~ ~ ~

SF #1238104 Internal sweep report was incorrect.

fixed by C. Valderrama

~ ~ ~

SF #1371274 The infamous Datatype unknown error when attempting some castings has been eliminated. It is now possible to use CAST to advise the engine about the datatype of a parameter.

fixed by D. Yemanov

~ ~ ~

SF #1292106 ORDER BY with FOR UPDATE WITH LOCK would trash the index.

fixed by D. Yemanov

~ ~ ~

SF #1368741 UPPER() was returning wrong results.

fixed by A. dos Santos Fernandes

~ ~ ~