Issue Details (XML | Word | Printable)

Key: CORE-1842
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Adriano dos Santos Fernandes
Reporter: Alex Karp
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

DEFAULT values are unnecessary evaluated

Created: 17/Apr/08 06:48 AM   Updated: 19/Jan/16 06:05 AM
Component/s: Engine
Affects Version/s: 2.5 Initial, 2.1 RC2
Fix Version/s: 2.5 Beta 1

Environment: Server version: WI-V6.3.0.17755 Firebird 2.1 Release Candidate 2
Issue Links:

QA Status: Done successfully

 Description  « Hide
create the table:

create table tb_date (
    tb_date_id integer not null primary key,
    f_date date default 0);

after this inse we attempt insert new record:

    1, '09-MAY-1945');


  insert into tb_date (
    tb_date_id, f_date)
  values (
    2, null);

and obtain the error:
The next statement causes the following error:
Overflow occurred during data type conversion.
conversion error from string "0".

although the inserted value f_date is correct - engine is checked the correctness default value of field f_date

Alex Karpeykin

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Adriano dos Santos Fernandes added a comment - 17/Apr/08 11:42 AM
First of all, Firebird doesn't support zero dates, so I'll rename the ticket description.

Second, I don't see this as a bug. Defaults are first evaluated and then assignments are made. Fields that doesn't are assigned become with the default value. So I'll change to improvement.

Dmitry Yemanov added a comment - 17/Apr/08 11:53 AM
Adriano, I disagree. While we of course don't support zero dates, the error is thrown for a perfectly valid SQL statement. And IMHO this is a bug, regardless of our internal algorithms.

Adriano dos Santos Fernandes added a comment - 17/Apr/08 12:06 PM
We support a very limited set of expressions in DEFAULT, so any (possible) incorrect DEFAULT are going to cause problem in an INSERT that needs to evaluate defaults.

I see this as an implementation detail (if the standard doesn't specify WHEN they should be evaluated) that *currently* doesn't affect real-life usage.