24.03.2017 10:50, Svein Erling Tysvær wrote: > Being still on Fb 2.5, my voice is rather error-prone, but I'm definitely > outside the development team.
Being long-time Firebird user your voice is very important for us > 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? We already have pseudo column with recno (dbkey) and transaction number. Probably it is time to add pseudo column with format number ? > 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? I prefer to see it works this way. Probably read-committed tx could return new default value. >> 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? I don't see how it could return different values. v2.5 will return same new default values, while v3 will return same initial default values. It doesn't matter if record was selected before default changes or not. > 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? Upgrade is happens with in-memory image of record only. No changes on disk until real explicit UPDATE. > 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. This could make sence if one knows that default value was changed after column was added. But when one don't knows it, one will confused why returned value is not the same as recorded in system catalog. > 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. Agree. > 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. Thanks for the opinion, it is very important to have feedback Vlad ------------------------------------------------------------------------------ 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
