On 26/03/17 22:43, Vlad Khorsun wrote:
>> That is what I would expect to see ...
>> As I stated in SET's reply I would expect to manage the change of a
>> default as appropriate, but the fall back should always be the stored
>> values? You would only see a 'new' default value if you added it, not
25.03.2017 0:16, Lester Caine wrote:
> On 24/03/17 21:42, Vlad Khorsun wrote:
>> 24.03.2017 21:36, Lester Caine wrote:
>>> On 24/03/17 17:57, Vlad Khorsun wrote:
> What must be done is specified exactly. And we should suppose that in
> all other aspects data stored in database should not
On 03/24/17 20:57, Vlad Khorsun wrote:
> 24.03.2017 19:39, Alex Peshkoff wrote:
>> On 03/24/17 20:26, Vlad Khorsun wrote:
>>> 24.03.2017 17:57, Alex Peshkoff wrote:
On 03/24/17 17:53, Vlad Khorsun wrote:
> So far we have no agreement on what is "correct result". Current
>
On 24/03/17 21:42, Vlad Khorsun wrote:
> 24.03.2017 21:36, Lester Caine wrote:
>> On 24/03/17 17:57, Vlad Khorsun wrote:
What must be done is specified exactly. And we should suppose that in
all other aspects data stored in database should not be changed -
>>>What data is *stored* ?
24.03.2017 21:36, Lester Caine wrote:
> On 24/03/17 17:57, Vlad Khorsun wrote:
>>> What must be done is specified exactly. And we should suppose that in
>>> all other aspects data stored in database should not be changed -
>>What data is *stored* ?
>
> For any field, the data that is loaded
On 2017-03-24 21:14, Mark Rotteveel wrote:
> To me 2ii) means that the behaviour should be that the newly added
> column **has** the value of the default clause, this can also be
> inferred from 11.5 .
>
> And I think clause 4 is relevant:
>
> """
> 4) In all other respects, the specification of
On 2017-03-24 07:26, Vlad Khorsun wrote:
> 24.03.2017 7:53, Vlad Khorsun wrote:
>> 24.03.2017 1:29, Mark Rotteveel wrote:
> ...
>>> The column was created with a default, which means that existing rows
>>> will get that value,
>>
>>Engine doesn't assing values to a new field, i.e. there is
On 24/03/17 17:57, Vlad Khorsun wrote:
>> What must be done is specified exactly. And we should suppose that in
>> all other aspects data stored in database should not be changed -
>What data is *stored* ?
For any field, the data that is loaded initially or later modified. And
I REPEAT ... if
24.03.2017 19:39, Alex Peshkoff wrote:
> On 03/24/17 20:26, Vlad Khorsun wrote:
>> 24.03.2017 17:57, Alex Peshkoff wrote:
>>> On 03/24/17 17:53, Vlad Khorsun wrote:
>>>
So far we have no agreement on what is "correct result". Current
implementation
changed well known old
24.03.2017 14:02, Ann Harrison wrote:
> It's been a long time, but I think that's an ancient behavior that Jim and I
> argued about many years ago.
> Maybe even in Rdb$ELN, InterBase's ancestor.
>
> Unless my memory fails me (again) the internal format rectifier doesn't go
> through all
24.03.2017 17:08, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 11:58, Vlad Khorsun escreveu:
>>> Well, actually seems we do not known why you started this topic mixing
>>> implementation details with users behaviour.
>>
>>Because you left blr filter for rdb$format broken and i going to
On 03/24/17 20:26, Vlad Khorsun wrote:
> 24.03.2017 17:57, Alex Peshkoff wrote:
>> On 03/24/17 17:53, Vlad Khorsun wrote:
>>
>>> So far we have no agreement on what is "correct result". Current
>>> implementation
>>> changed well known old behaviour not claiming it as a bug. I'd say it looks
24.03.2017 17:12, Adriano dos Santos Fernandes wrote:
...
> Looks like you do not understand how it works. Re-read thread "Adding
> NOT NULL fields with DEFAULT" from 2009.
That thread contains more details, thanks for recall it.
>>> Correct result is priority, and current implementation
24.03.2017 17:57, Alex Peshkoff wrote:
> On 03/24/17 17:53, Vlad Khorsun wrote:
>
>> So far we have no agreement on what is "correct result". Current
>> implementation
>> changed well known old behaviour not claiming it as a bug. I'd say it looks
>> like
>> a bug itself.
>
> Vlad, looking at
On 03/24/17 17:53, Vlad Khorsun wrote:
> So far we have no agreement on what is "correct result". Current
> implementation
> changed well known old behaviour not claiming it as a bug. I'd say it looks
> like
> a bug itself.
Vlad, looking at sql2008 (part2, foundation, 11.10 - alter table
On 24/03/17 15:12, Adriano dos Santos Fernandes wrote:
>> Current implementation
>> changed well known old behaviour not claiming it as a bug. I'd say it looks
>> like
>> a bug itself.
>>
> Changed a bugged design/implementation since 2009. Looks a bit late to
> say this.
I'm still running FB1.5
Em 24/03/2017 11:53, Vlad Khorsun escreveu:
> 24.03.2017 16:31, Adriano dos Santos Fernandes wrote:
>
>> Or better, increase the record format count, which seems as a stupid limit.
>
>It is really better. Are you have smart idea ?
>
>> From another side, storing the default value
Em 24/03/2017 11:58, Vlad Khorsun escreveu:
>> Well, actually seems we do not known why you started this topic mixing
>> implementation details with users behaviour.
>Because you left blr filter for rdb$format broken and i going to fix it
> and start palying with default values.
>
Where is
24.03.2017 16:34, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 06:44, Vlad Khorsun escreveu:
>
>>
>>I prefer to see it works this way. Probably read-committed tx could
>> return new default value.
>>
>
> Not only it is in no way intuitive, it would be impossible to use indexes.
24.03.2017 16:37, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 11:15, Vlad Khorsun escreveu:
>> 24.03.2017 15:58, Adriano dos Santos Fernandes пишет:
>>> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>>>
actual
ID DESCRF1
>
> Note value of the field F1 at the first record: it is expected that is should
> be the same as latest DEFAULT value.
> Also note that 2nd and 3rd INSERTs assigns correct value to the omitted field
> - same as latest DEFAULT value.
If you re-read thread "Adding NOT NULL fields with DEFAULT"
24.03.2017 16:31, Adriano dos Santos Fernandes wrote:
> Or better, increase the record format count, which seems as a stupid limit.
It is really better. Are you have smart idea ?
> From another side, storing the default value inside the format is a
> smart hack that allows to avoid
Em 24/03/2017 11:15, Vlad Khorsun escreveu:
> 24.03.2017 15:58, Adriano dos Santos Fernandes пишет:
>> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>>
>>>
>>> actual
>>>
>>> ID DESCRF1
>>>
>>>
Em 24/03/2017 06:44, Vlad Khorsun escreveu:
>
>I prefer to see it works this way. Probably read-committed tx could return
> new default value.
>
Not only it is in no way intuitive, it would be impossible to use indexes.
Adriano
PS: still trying to understand why you want to change a
Em 24/03/2017 11:19, Vlad Khorsun escreveu:
> 24.03.2017 16:03, Adriano dos Santos Fernandes wrote:
>> Em 24/03/2017 03:33, Vlad Khorsun escreveu:
>>
>>>
>>>Another example - i add not null column with wrong default value and
>>> going to correct this wrong default value. Should i update whole
24.03.2017 16:03, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 03:33, Vlad Khorsun escreveu:
>
>>
>>Another example - i add not null column with wrong default value and
>> going to correct this wrong default value. Should i update whole table
>> to do it ?
>>
>
> Drop the column and
24.03.2017 15:58, Adriano dos Santos Fernandes пишет:
> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>
>>
>> actual
>>
>> ID DESCRF1
>>
>>1 No F1 field XYZ
>>
Em 24/03/2017 04:18, Dmitry Yemanov escreveu:
>
> Also, lets consider this:
>
> SQL> create table t (col1 int);
> SQL> insert into t values (1);
> SQL> commit;
> SQL> alter table t add col2 int default 123 not null;
> SQL> select * from t;
>
> COL1 COL2
>
Em 24/03/2017 03:33, Vlad Khorsun escreveu:
>
>Another example - i add not null column with wrong default value and
> going to correct this wrong default value. Should i update whole table
> to do it ?
>
Drop the column and recreate it, fixing your error.
>> From another side, storing
Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>
> actual
>
> ID DESCRF1
>
>1 No F1 field XYZ
>2 F1 field, default XYZXYZ
>3
It's been a long time, but I think that's an ancient behavior that Jim and I
argued about many years ago. Maybe even in Rdb$ELN, InterBase's ancestor.
Unless my memory fails me (again) the internal format rectifier doesn't go
through all intermediate formats, it just converts from the stored
24.03.2017 12:28, Dimitry Sibiryakov wrote:
> 24.03.2017 10:29, Vlad Khorsun wrote:
>>Not sure i understand what you mean but sweep never updates records.
>
>My knowledge of Firebird is overestimated, you know. Isn't there an
> internal routine
> that converts records into the latest
24.03.2017 10:29, Vlad Khorsun wrote:
>Not sure i understand what you mean but sweep never updates records.
My knowledge of Firebird is overestimated, you know. Isn't there an internal
routine
that converts records into the latest format whenever it reads them?
--
WBR, SD.
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
On 03/24/17 06:25, Adriano dos Santos Fernandes wrote:
> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>> To me the behavior described under "actual" intuitively sounds like the
>> correct behavior. Why do you expect that the column value would change
>> to 'ABC'?
>>
>> The column was created with
On 24/03/17 08:50, Svein Erling Tysvær 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
24.03.2017 6:53, Vlad Khorsun wrote:
>Engine doesn't assing values to a new field, i.e. there is no implicit
> UPDATE of
> the existing records. This is strong point of the engine, btw.
Is it possible that in your testcase sweep performed implicit update between
DDLs?
--
WBR, SD.
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
Hi!
I expect form the FB engine to return the default value at INSERT/UPDATE
TIME, not the current default value. So default values should be kept in
the rdb$format table, because versioning is needed.
On 2017.03.24. 8:18, Dmitry Yemanov wrote:
> 24.03.2017 09:33, Vlad Khorsun wrote:
>>>
24.03.2017 09:33, Vlad Khorsun wrote:
>
>> 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
24.03.2017 7:53, Vlad Khorsun wrote:
> 24.03.2017 1:29, Mark Rotteveel wrote:
...
>> The column was created with a default, which means that existing rows will
>> get that value,
>
>Engine doesn't assing values to a new field, i.e. there is no implicit
> UPDATE of
> the existing records.
24.03.2017 02:29, Mark Rotteveel wrote:
> To me the behavior described under "actual" intuitively sounds like the
> correct behavior. Why do you expect that the column value would change
> to 'ABC'?
This is really a tricky case. The "replace non-existing value with the
default one" hack is a
24.03.2017 1:29, Mark Rotteveel wrote:
> To me the behavior described under "actual" intuitively sounds like the
> correct behavior. Why do you expect that the column value
> would change to 'ABC'?
Because Firebird doesn't update old records when new field was created.
> The column was
Em 23/03/2017 20:29, Mark Rotteveel escreveu:
> To me the behavior described under "actual" intuitively sounds like the
> correct behavior. Why do you expect that the column value would change
> to 'ABC'?
>
> The column was created with a default, which means that existing rows
> will get that
To me the behavior described under "actual" intuitively sounds like the correct
behavior. Why do you expect that the column value would change to 'ABC'?
The column was created with a default, which means that existing rows will get
that value, afaik it shouldn't change if the default later is
45 matches
Mail list logo
