Being still on Fb 2.5, my voice is rather error-prone, but I'm definitely
outside the development team.
It would confuse me if things worked like Vlad expects. Suppose the query
was "select * from t where ID between 1 and 2", then I would ask myself why
record 1 changed value when record 2 retained it when the only change done
was the default value. From a theoretical point of view, I can see Vlads
point of him expecting a 'floating default' as opposed to the 'fixed
default', but it does make it harder for users when selects may return
values that aren't really there. And if you didn't know whether record 1
was inserted before or after the addition of field1, is there a simple way
to tell that this record has a floating default whereas record 2 has a
fixed default?
I try to avoid making trouble through doing DDL and DML simultaneously, but
what if there was an active transaction that started before the default was
changed to ABC. Would Vlad expect that transaction to still return XYZ for
record 1 whereas all newer transactions would return ABC?
> Firebird is known to upgrade the record format while reading. "Upgrade"
> here means using the latest (aka current) format. The current format is
> the one that can be seen in RDB$RELATION_FIELDS. So one may expect that
> the default value to be used is also the latest one, that's stored in
> RDB$ tables
This also complicates things. Does it mean that if we before creating F1
also had inserted:
INSERT INTO T (ID, DESCR) VALUES (4, 'No F1 field');
and that this record had never been selected before the change of default
from XYZ to ABC, then "select F1 from t where ID in (1, 4)" after this
change would return different values for F1 despite the only difference
between them being that one of them were selected when XYZ was the default?
And does an "Upgrade" such as Dmitry describes also happen when doing
"select count(*) from t" and/or in read-only transaction or even read-only
databases?
To me, the most logical thing would be that all fields got the default
value when the record was inserted, and if the record was inserted before
the default was created, then that the first default would be the value
that the record got. I think this is more or less what Mark and Adriano
wrote.
I would expect changing defaults for fields that didn't have a default when
records were inserted and that haven't explicitly received any value since,
to be something that isn't all too common. Normally, I would expect running
an "update T set F1 = 'XYZ' where F1 is null" shortly before or after
setting such a default (assuming this would set the value even if issued
after setting the default), but this may be just me and/or Fb 2.5. Note
that I never work against huge databases.
Set
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
