01.04.2011 11:24, Dmitry Yemanov wrote:
> 01.04.2011 13:07, Dimitry Sibiryakov wrote:
>
>> It will be his/her problem. Restore backup.
>
> And loose a few hours/days of production work?
Yep. Price of mistake is high. That's cruel life.
>> If user has a many-gigabytes table, validation time wil
01.04.2011 13:07, Dimitry Sibiryakov wrote:
> It will be his/her problem. Restore backup.
And loose a few hours/days of production work?
> If user has a many-gigabytes table, validation time will be big.
Sure. But recovery of such a database in the case of user mistake will
take much longer.
Den 2011-04-01 11:07 skrev Dimitry Sibiryakov såhär:
> 01.04.2011 11:03, Dmitry Yemanov wrote:
> > I'm against this. But feel free to keep arguing :-)
>
> If user has a many-gigabytes table, validation time will be big.
Tell me about it... I have a 52 gigabyte DB with two 150 million record
01.04.2011 11:00, Kjell Rilbe wrote:
> Good idea, but what if the user later turns out to have been wrong? How
> to handle it?
It will be his/her problem. Restore backup.
01.04.2011 11:03, Dmitry Yemanov wrote:
> I'm against this. But feel free to keep arguing :-)
If user has a many-gigab
01.04.2011 12:53, Dimitry Sibiryakov wrote:
> May I suggest to add non-standard optional clause NOVALIDATE for users who
> are sure
> that validation is unnecessary and want to save time on commit?..
I'm against this. But feel free to keep arguing :-)
Dmitry
--
On 04/01/11 11:47, Dmitry Yemanov wrote:
> 01.04.2011 11:19, Kjell Rilbe wrote:
>
>> I'm not sure I made much sense... Tell me, does the standard specify
>> anything regarding datatype change features? If so, what does it say?
> It allows to alter a string column to a string one of the non-shorter
Den 2011-04-01 10:53 skrev Dimitry Sibiryakov såhär:
> 01.04.2011 10:47, Dmitry Yemanov wrote:
>> Personally, I don't see problems with combining both approaches, i.e.
>> use the fast "versioning" mode for the a priori valid changes and
>> perform the explicit validation for possibly problematic ch
01.04.2011 10:47, Dmitry Yemanov wrote:
> Personally, I don't see problems with combining both approaches, i.e.
> use the fast "versioning" mode for the a priori valid changes and
> perform the explicit validation for possibly problematic changes. This
> way we could easily allow altering string co
01.04.2011 12:05, Kjell Rilbe wrote:
> While writing this, I do feel that it would be rather nice if Firebird
> could automatically do all this:
>
> 1. Transliterate/cast existing data to new type, raising erors if data
> can't be converted.
FWIW, this is somewhat against the design Firebird inhe
Den 2011-04-01 10:38 skrev Dmitry Yemanov såhär:
> Your copy is outdated :-) My version of 2010-10-14 says:
>
> ::=
> ALTER TABLE
>
> ::=
>
> |
> |
> |
> |
> |
> |
> |
> |
>
> ::=
> ALTER [ COLUMN ]
>
> ::=
>
> |
> |
> |
> |
> |
> |
> |
> |
> |
>
> ::=
> SET DATA TYPE
Where can I f
01.04.2011 12:24, Alex Peshkoff wrote:
> Dmitry, where have you found a reference in standard tat string column
> can be altered to wider one type?
> What Is see in SQL2008 is:
Your copy is outdated :-) My version of 2010-10-14 says:
::=
ALTER TABLE
::=
|
|
|
|
|
|
|
|
::=
ALTER
On 04/01/11 11:47, Dmitry Yemanov wrote:
> 01.04.2011 11:19, Kjell Rilbe wrote:
>
>> I'm not sure I made much sense... Tell me, does the standard specify
>> anything regarding datatype change features? If so, what does it say?
> It allows to alter a string column to a string one of the non-shorter
01.04.2011 11:51, Dimitry Sibiryakov wrote:
> I don't understand why this job is deferred. If DDL is impossible, user must
> be informed
> about this fact ASAP.
In order to perform the validation, you have to lock the table from
concurrent modifications. If it's done ASAP and the lock is then
Den 2011-04-01 09:47 skrev Dmitry Yemanov såhär:
> 01.04.2011 11:19, Kjell Rilbe wrote:
>
>> I'm not sure I made much sense... Tell me, does the standard specify
>> anything regarding datatype change features? If so, what does it say?
>
> It allows to alter a string column to a string one of the no
01.04.2011 8:48, Dmitry Yemanov wrote:
> I believe we need to brainstorm this. Should we rollback all these
> fixes? Should we allow them but add the proper consistency checks, e.g.
> allow ASCII->any-single-byte-or-utf8 and any->UTF8 conversions and
> disallow everything else? Should we add a DFW
01.04.2011 11:19, Kjell Rilbe wrote:
> I'm not sure I made much sense... Tell me, does the standard specify
> anything regarding datatype change features? If so, what does it say?
It allows to alter a string column to a string one of the non-shorter
length. This is how FB works since the beginni
Den 2011-04-01 08:48 skrev Dmitry Yemanov såhär:
> All,
Well I'm not a developer so feel free to ignore me. I answer from the
point of view of a FB user.
[snip examples and text about altering charset/collation on existing
columns]
> However, now I doubt whether it's correct at all. By design,
All,
In the past, I resolved CORE-1058 by making DYN_MOD aware of these
attributes. Recently, Adriano has also fixed CORE-2426 in the same area.
However, this simple test still fails:
create table test (col char(10) character set win1251);
alter table test alter col type char(10) character set
18 matches
Mail list logo
