diff --git a/doc/README.incompatibilities.3to4.txt b/doc/README.incompatibilities.3to4.txt index 1e3bc047da..e2c62ad251 100644 --- a/doc/README.incompatibilities.3to4.txt +++ b/doc/README.incompatibilities.3to4.txt @@ -12,7 +12,6 @@ the new Firebird version. Deprecating UDF -------------------------- - * Initial design of UDF always used to be security problem. The most dangerous security holes when UDFs and external tables are used simultaneousky were fixed in FB 1.5. But even after it incorrectly declared (using SQL statement @@ -29,3 +28,29 @@ Deprecating UDF path-list is just UDF and resulting line in firebird.conf should be: UdfAccess = Restrict UDF Recommended long-term solution is replacing of UDF with UDR. + + +Non-constant date/time/timestamp literals +----------------------------------------- + * There is date, time and timestamp literals with this syntax: + DATE '2018-01-01' + TIME '10:00:00' + TIMESTAMP '2018-01-01 10:00:00' + + They are parsed at compile time. + + However, there are weird situation with some literals. + + We may use things as DATE 'TODAY', DATE 'TOMORROW', DATE 'YESTERDAY', TIME 'NOW' and TIMESTAMP 'NOW'. + + And different than these strings used in CAST, these are literais + (evaluated at compile time). + + So if you create a procedure/function with them, they value are + refreshed every time you recompile (from SQL) the routine, but never + refreshed when you run it. + + Also imagine a compiled statement cache (implementation detail), a + "select timestamp 'now' from rdb$database" will give stalled results. + + These strings will not be accepted with the literals syntax anymore.