Skip to content
Permalink
master
Go to file
 
 
Cannot retrieve contributors at this time
73 lines (54 sloc) 3.22 KB
********************************************************************************
LIST OF KNOWN INCOMPATIBILITIES
between versions 3.0 and 4.0
********************************************************************************
This document describes all the changes that make v4.0 incompatible in any way
as compared with the previous releases and hence could affect your databases and
applications.
Please read the below descriptions carefully before upgrading your software to
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
DECLARE EXTERNAL FUNCTION) UDF can easily cause various security issues like
server crash or execution of arbitrary code. Therefore UDFs are deprecated
in v4. That means that UDFs can't be used with default configuration
(parameter "UdfAccess" set to "None") and all sample UDF libraries (ib_udf,
fbudf) are not distributed any more. Most of functions in that libraries
were replaced with builtin analogs in previous versions and therefore
already deprecated. A few remaining functions got safe replacement in UDR
library "udf_compat", namely div, frac, dow, sdow, getExactTimestampUTC and
isLeapYear. Users who still wish to use UDFs should set "UdfAccess" to
"Restrict <path-list>". If you never used to modify this parameter before
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.
Start value of sequences
------------------------
* Before v4 sequences were created with its current value set to its start value (or the default zero).
Then a sequence with a start value of 0 and increment 1 started at 1. This example has the same
result in v4 but internals are different, and that makes others cases different.
In v4 sequences are created (or restarted) with its current value set to its start value minus
its increment. And the default start value is changed to 1.
Then a sequence with start value 100 and increment 10 has its first NEXT VALUE equal to 100 in v4,
while it was 110 before.
Likewise this sequence has its first GEN_ID(SEQ, 1) equal 91 in v4, while it was 101 before.
You can’t perform that action at this time.