singhpk234 commented on code in PR #16777: URL: https://github.com/apache/iceberg/pull/16777#discussion_r4487864972
########## format/spec.md: ########## @@ -372,6 +373,14 @@ The `initial-default` is set only when a field is added to an existing schema. T The `initial-default` and `write-default` produce SQL default value behavior, without rewriting data files. SQL default value behavior when a field is added handles all existing rows as though the rows were written with the new field's default value. Default value changes may only affect future records and all known fields are written into data files. Omitting a known field when writing a data file is never allowed. The write default for a field must be written if a field is not supplied to a write. If the write default for a required field is not set, the writer must fail. +In v4, a field's `write-default` may be a [value expression](expressions-spec.md). This allows defaults such as `current_timestamp()` to be evaluated when a row is written. A value expression `write-default` is subject to the following requirements: + +* The expression must be a constant or a function application (apply); [field references](expressions-spec.md#field-reference) are not allowed in a default value expression +* The expression must produce a value of the field's type, subject to [type promotion](#schema-evolution) Review Comment: is this understanding correct : when the field is bounded to schema and the type this field has now, should be type what the value expression would produce should be same or can be promoted to bounded field type ? if yes can we expand the current text to elaborate a bit more on subject to type-promotion ########## format/spec.md: ########## @@ -372,6 +373,14 @@ The `initial-default` is set only when a field is added to an existing schema. T The `initial-default` and `write-default` produce SQL default value behavior, without rewriting data files. SQL default value behavior when a field is added handles all existing rows as though the rows were written with the new field's default value. Default value changes may only affect future records and all known fields are written into data files. Omitting a known field when writing a data file is never allowed. The write default for a field must be written if a field is not supplied to a write. If the write default for a required field is not set, the writer must fail. +In v4, a field's `write-default` may be a [value expression](expressions-spec.md). This allows defaults such as `current_timestamp()` to be evaluated when a row is written. A value expression `write-default` is subject to the following requirements: + +* The expression must be a constant or a function application (apply); [field references](expressions-spec.md#field-reference) are not allowed in a default value expression +* The expression must produce a value of the field's type, subject to [type promotion](#schema-evolution) +* The `write-default` expression is evaluated to populate the field for any record written after the field was added when the writer does not supply the field's value Review Comment: > evaluated to populate the field for any record written after the field was added when the writer does not supply the field's value what about multi-statement transaction, at this point this field is not added to the table but we still wanna add data to it ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
