[
https://issues.apache.org/jira/browse/IGNITE-20907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796593#comment-17796593
]
Evgeny Stanilovsky commented on IGNITE-20907:
---------------------------------------------
all transitions for now mapped here :
CatalogUtils#ALTER_COLUMN_TYPE_TRANSITIONS
> Support column type changes that do not require existing data conversion
> ------------------------------------------------------------------------
>
> Key: IGNITE-20907
> URL: https://issues.apache.org/jira/browse/IGNITE-20907
> Project: Ignite
> Issue Type: Epic
> Components: sql
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> Currently, only a small number of <from, to> pairs are allowed when changing
> a column type with ALTER TABLE ... ALTER COLUMN... SET DATA TYPE, see
> [IEP-108|https://cwiki.apache.org/confluence/display/IGNITE/IEP-108+Change+column+type#IEP108Changecolumntype-Proposal.].
> When it comes to columns that are not indexed, we can increase the set of
> allowable type changes: we can allow any change for which we can guarantee
> that any value that is a member of the original type is represented
> losslessly in the new type (in other words, any value converted from the
> original type to the new type and then converted back will produce the same
> value as before the double conversion). Each tuple is accompanied with table
> version in the MV storage, so we can always determine the corresponding
> schema version V and convert the value in memory when it's read using any
> table version V' (where V'>=V). We already have a mechanism of upgrading
> adapters on read, the mecnanism can be leveraged for type conversion.
> As for indexed columns, the simpliest solution for now is to leave the
> current (strict) rules for changing their types as indices seem to require
> that the binary representation of all values in the original type remains the
> same to avoid index rebuild. This can be addressed later.
> The set of allowable type changes (probably incomplete, this has to be
> carefully checked) follows:
> * INT(N) -> INT(M), where N<M
> * FLOAT -> DOUBLE
> * INT(N) -> FLOAT/DOUBLE (where N guarantees backward convertibility for
> each INT(N) value; for instance, for FLOAT N=8/16)
> * INT(N) <-> NUMBER(P, S), where N, P, S guarantee lossless conversion
> * INT(N) <-> DECIMAL(P, S), where N, P, S guarantee lossless conversion
> * NUMBER(P1, S1) <-> DECIMAL(P1, S1), where parameters guarantee lossless
> conversion
> * NUMBER(P1, S1) <-> NUMBER(P1, S1), where parameters guarantee lossless
> conversion
> * DECIMAL(P1, S1) <-> DECIMAL(P1, S1), where parameters guarantee lossless
> conversion
> * STRING(L1) -> STRING(L2), where L1<L2
> * <any mentioned type but floating point> <-> STRING(L), where parameters
> guarantee lossless conversion
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
