[
https://issues.apache.org/jira/browse/IGNITE-21384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815371#comment-17815371
]
Andrey Mashenkov commented on IGNITE-21384:
-------------------------------------------
I suggest to split the problem into 2 tickets.
# Support non-volatile functions (or expressions) in DEFAULT clase.
This has a straightforward solution, does NOT require updating all the existing
rows in a table, and will allow using CURRENT_TIMESTAMP function in DEFAULT
clause. As I understand, that was the major issue that cause this ticket.
# Support volatile function (or expressions) in DEFAULT clase.
That is what is this ticket description about. The solution requires to update
existing data, and covers the case with 'random value' as a column default.
> Initialize all rows with new column's default value
> ---------------------------------------------------
>
> Key: IGNITE-21384
> URL: https://issues.apache.org/jira/browse/IGNITE-21384
> Project: Ignite
> Issue Type: New Feature
> Reporter: Maksim Myskov
> Priority: Major
> Labels: ignite-3
>
> In case of adding a new column with a default value specified (for example:
> ALTER TABLE ADD COLUMN col INT DEFAULT 10), all existing rows (that were
> added before "alter table") must be initialized with a new value.
> h3. Current behaviour
> The default value of a column is evaluated on read.
> h3. Motivation
> This is a pre-requisite for adding arbitrary expressions as default values.
> Let's imagine a simple case:
> {code:sql}
> ALTER TABLE ADD COLUMN modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP
> {code}
> With the current behavior for all existing rows the value of "modified"
> column will be evaluated on every read.
> Many DBs use the proposed behavior:
> * PostgreSQL
> * CockroachDB
> * Yugabyte
> For example, from PostgreSQL
> [docs|https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-NOTES]:
> {noformat}
> Adding a column with a volatile DEFAULT or changing the type of an existing
> column will require the entire table and its indexes to be rewritten.
> {noformat}
> h3. Downsides
> Adding a new column with a default value will be a much more expensive
> operation and can take a significant time on large tables
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
