Spec: Add spec for expressions by rdblue · Pull Request #16652 · apache/iceberg

rdblue · 2026-06-02T00:00:40Z

This adds a spec for expressions, which was proposed in the Extending Iceberg Expressions design doc.

singhpk234

This is awesome ! Thanks @rdblue !

singhpk234 · 2026-06-02T16:35:14Z

+| `IS NULL`               | any           |               | true iff the value is null |
+| `IS NOT NULL`           | any           |               | true iff the value is not null |


minor: may be we should link supported iceberg data tyes in the spec

danielcweeks · 2026-06-03T20:27:21Z

+A constant or literal is the simplest type of value expression that represents a specific typed value.
+
+
+#### Field reference


In looking around, other systems have two other reference types that I want to callout (though I don't necessarily think we want to include, but should consider):

Positional References (for row-like references)

Subscripted References (indexing into arrays)

For subscripted references, we can use a well-defined function, like get_item. I don't think that we want to have this in the spec since it fits cleanly into a function. And that would also requiring choosing either 1-based or 0-based indexing. With functions, we can model both: get_item_the_right_way for 0-based, get_item_sql for 1-based. 😄

I don't think that we want to include positional references.

Looks like Trino uses element_at: https://trino.io/docs/current/functions/array.html#element_at

danielcweeks · 2026-06-03T20:30:43Z

+
+A value expression's type is determined when it is bound to a specific input schema.
+
+If types are incompatible at runtime, implementations binding or evaluating expressions may apply type promotion to align types for predicates and to resolve functions. Implementations may choose when to promote values to accomodate engines that differ in casting behavior. However, implementations must fail rather than insert "unsafe" casts. 


Is this always implicitly handled by the engine? Do we consider CAST(...) something that would fall under a sql_functions.cast or should we leave it out entirely.

I think that sql_functions.cast can be used for explicit casts, but I want to avoid adding a cast definition in this spec for the expression structure.

RussellSpitzer · 2026-06-04T20:35:27Z

+
+This approach is intended to keep focus on the logical structure of expressions. Complexity is pushed to the functions that are called, which can be a limited set of well-defined and portable functions (like Iceberg partition transforms) or could be user-defined functions that can use the full range of SQL capabilities. Multi-dialect UDFs are responsible for any SQL constructs that are specific to an engine, rather than importing and duplicating dialects in Iceberg expressions.
+
+This is consistent with Iceberg's conservative approach in other specs. Expressions and predicates are an important part of Iceberg implementation APIs, but have been deliberately limited in specifications. For example, sort orders and partition fields are strictly limited to a small set of transforms over well-defined inputs (source field IDs). This spec is widening what can be expressed, but depends on function calls for complex tasks.


More of a "why this is written in the way it is" than a "what this spec is about". Just wondering if we need this paragraph in the text.

That's fair. I can remove it if you think it isn't useful.

My goal would be the Spec is just what would be needed to implement expressions correctly. So I would remove or maybe just start a whole new doc about Iceberg's core values.

Yeah not strongly opinionated here but I find this to just be extra stuff that isn't super valuable in the context of the spec itself. A separate core values or design principles would be valuable though.

RussellSpitzer · 2026-06-04T20:47:24Z

+
+Engines may document and use a catalog name to identify their built-in functions that are not part of the SQL spec, like `spark_builtin_functions.to_utc_timestamp`.
+
+Producers are responsible for resolving catalog, namespace, and name if the environment is relevant. For example, if a SQL engine uses its current catalog and namespace to find a function, the resolved catalog and namespace must be used to produce an unambiguous function identifier.


I'm not sure I understand this statement either. Is this just saying that a engine is allowed to resolve an identifier however it likes as long as it would be doing so unambigously?

Clarified by adding:

Function identifiers are unambiguous and are not interpreted using session context.

What I am trying to say is that identifiers are fully-qualified and identify a single object. In a SQL query, I could use a function like parse_device_id, which is resolved using my session's current catalog and namespace to prod.website.parse_device_id. The identifier when referencing that function must be {"catalog": "prod", "namespace": ["website"], "name": "parse_device_id"}. The identifier is not dependent on session context.

I should also note that "catalog" could be omitted to use the catalog where the referencing object is stored.

RussellSpitzer · 2026-06-04T21:05:54Z

+
+A value expression's type is determined when it is bound to a specific input schema.
+
+If types are incompatible at runtime, implementations binding or evaluating expressions may apply type promotion to align types for predicates and to resolve functions. Implementations may choose when to promote values to accomodate engines that differ in casting behavior. However, implementations must fail rather than insert "unsafe" casts. 


I understand the intent here but adding "unsafe" feels ambiguous here.

We used unsafe in the UDF spec as well:

Require explicit casts for unsafe or non-obvious conversions.

I'll remove the quotes because that makes this more confusing. We do delegate to engines what casts they want to produce, but I think it's fairly well understood in most cases.

RussellSpitzer · 2026-06-04T21:07:34Z

+
+Predicates can be constants (true or false), comparisons or tests of value expressions, or logical combinations of predicates (AND, OR, NOT).
+
+If value expression types in a predicate are incompatible, implementations should align types using type promotion. For instance, `int_col > 5.0` should promote int values to float. If the types cannot be aligned according to type promotion rules, the predicate must evaluate to false. For instance, `"goats" > -Infinity` should always be `false`.


I feel like we are again dancing around what it is a "safe" type promotion and what is allowed. The above examples make sense to me but for me the dangerous ones are always things like

2141041920 > '05-04-19` or whatnot

What I'm trying to say is that implementations should fail the dangerous cases.

I get the argument that this is not exact, but we are delegating this responsibility to engines so that their rules are applied consistently. I think that most engines have well-defined lines between safe and unsafe casts. But there are some situations like promoting decimals to wider scale that could differ.

RussellSpitzer · 2026-06-04T21:23:57Z

+* `fixed` and `binary` use unsigned byte-wise comparison
+* `string` uses unsigned byte-wise comparison of the UTF-8 representation
+* `uuid` uses unsigned byte-wise comparison of the UUID bytes
+* `float` and `double` use IEEE 754 total order after normalizing NaN to the canonical NaN (sign bit 0, exponent bits all 1, matissa msb 1 followed by all 0)


Just wondering why we don't want to follow the IEE standard here and do -Nan < Nan?

We use NaN counts in stats because IEEE total ordering can easily destroy the effectiveness of lower/upper bounds with just one NaN value. Since we treat all NaN values as the same thing in our stats, I wanted to be consistent here and also push people to use IS NAN and NOT NAN predicates instead of = NaN.

I think we have to support NaN here; the non-total-order IEEE comparison causes a ton of headaches because NaN != NaN. But I wanted to keep the intrusion minimal. Plus, "negative not a number" is a thing because of the bit representation. And I don't think we want to keep signaling NaN here either, which would be a whole class of cases where apparent NaN < NaN is true or false, or just confusing because you don't display the mantissa.

RussellSpitzer · 2026-06-23T16:25:32Z

+* `fixed` and `binary` use unsigned byte-wise comparison
+* `string` uses unsigned byte-wise comparison of the UTF-8 representation; it is not the Unicode Collation Algorithm
+* `uuid` uses unsigned byte-wise comparison of the UUID bytes
+* `float` and `double` use IEEE 754 total order after normalizing NaN to the canonical NaN (sign bit 0, exponent bits all 1, mantissa msb 1 followed by all 0)


I thought I added a comment here before but I was wondering why we want the cannonical nan here when we don't use it this way in the Table Format spec (-Nan < Nan )

My original answer is here: #16652 (comment)

I'd probably rephrase that to make the logic a bit more clear though. First, table stats don't allow NaN values for lower or upper bounds. NaN values are counted and the bounds reflect all non-NaN values. That is because NaN values can easily destroy the effectiveness of stats, since any NaN value is greater than (or -NaN is less than) all other floating point values. I think that the rules here for expressions are as consistent with this as we can be.

For expressions, we want to handle NaN like null: we don't want wacky comparison behavior and we want everyone to use IS NaN and IS NOT NaN to explicitly specify how to handle NaN values.

What do I mean by "wacky comparison behavior"? In the IEEE 754 non-total-order case, NaN = NaN is false and comparisons of values with NaN are always false. You get the bad behavior where the order of comparison matters (a < NaN is false and NaN < a is false, but a is not NaN) and so NaN values can show up in either upper or lower bounds (and sometimes both!). IEEE 754 total order isn't much better: NaN = NaN is true if they have the same bits, but NaN < NaN can also be true.

These quirks are not obvious, which is why we typically want people to use the IS NaN and IS NOT NaN forms. However, just like we have to handle null values produced by functions, we also have to handle NaN values when they show up as the results of functions (like divide(a, b) for a=0.0 and b=0.0).

Because we can't completely eliminate NaN comparisons, we have to define how they work. I think the most predictable and understandable way is using the two rules just below: NaN = NaN is true for any two NaN values, and all non-NaN values are less than NaN.

One additional choice I made was not to handle -NaN and NaN separately. I think -NaN isn't very useful so I chose the simpler option to normalize all NaN values.

After thinking about this more and talking offline with @RussellSpitzer, we decided to update the wording so that NaN behavior is the same as null handling. This consistency makes both nominally incomparable cases behave the same way.

This could cause situations like those mentioned above where aggregations with NaN values behave strangely based on the order of operands. I think consistency is more important and that NaN handling should always be explicit using IS NaN, just like IS NULL is the correct way to handle null values. In addition, the use cases contemplated by this spec (for instance CHECK constraints) are unlikely to hit these cases.

stevenzwu

a couple minor comments

stevenzwu · 2026-06-25T01:29:12Z

+
+Functions are referenced using a catalog and a function identifier (list of strings).
+
+* The function identifier consists of 0 or more namespace names followed by the function name. At least one part, the function name, is required.


This prose rule ("at least one part, the function name, is required") is not enforced by the grammar in Appendix B, which uses [ NAME* ] for all three structured FUNC_REF forms:

FUNC_REF: NAME | [ NAME* ] | { "identifier": [ NAME* ] } | { "catalog": NAME, "identifier": [ NAME* ] }

Use [ NAME+ ] (one-or-more) so the grammar matches the prose:

FUNC_REF: NAME | [ NAME+ ] | { "identifier": [ NAME+ ] } | { "catalog": NAME, "identifier": [ NAME+ ] }

I don't think it's a problem for the grammar to be wider than what we actually allow, but I think we can tighten it up if this is important.

szehon-ho · 2026-06-25T05:26:05Z

missed a lot of the discussion, but well thought out. Was reading the predicate/expression part, the 'Value expressions are not valid predicates' is a nice way to reduce the chance for null ambiguity:

if_else(f(x), "A", "B") //ambiguious if f(x) is null (not allowed)
if_else(f(x) = true, "A", "B")

manuzhang · 2026-06-25T09:53:42Z

+### Backward compatibility
+
+```
+DEPRECATED_PREDICATE:


how about { "type": "true" } and { "type": "false" }?

Is this currently allowed?

iceberg/open-api/rest-catalog-open-api.yaml

Lines 2562 to 2578 in a2fb64b

TrueExpression:

type: object

required:

- type

properties:

type:

$ref: '#/components/schemas/ExpressionType'

const: "true"

FalseExpression:

type: object

required:

- type

properties:

type:

$ref: '#/components/schemas/ExpressionType'

const: "false"

I created a folllow-up PR #17120. Please help review.

wgtmac · 2026-06-25T14:33:12Z

+
+Function calls may produce different types when function definitions change, and type changes may change the definition that is resolved for a function name. For example, if the input field passed to `identity(int) -> int` is promoted from `int` to `long`, the resolved `identity` function can change to `identity(long) -> long` if it is defined.
+
+If types are incompatible at runtime, implementations binding or evaluating expressions may apply type promotion to align types for predicates and to resolve functions. Implementations may choose when to promote values to accommodate engines that differ in casting behavior. However, implementations must fail rather than insert unsafe casts.


Is type promotion here identical to iceberg type promotion rule? I assume no.

It is not. Type promotion is delegated to implementations: "Implementations may choose when to promote values to accommodate engines that differ in casting behavior"

wgtmac · 2026-06-25T14:35:39Z

+* `sql_functions` is used for functions defined by the SQL standard
+* `iceberg_functions` is used for functions defined in this specification
+
+Engines may document and use a catalog name to identify their built-in functions that are not part of the SQL spec, like `spark_builtin_functions.to_utc_timestamp`.


So we have the risk that a non-interchangeable engine-specific expression used by a Iceberg table would ruin its interoperability?

Expressions are not engine-specific, but functions may be.

That said, there are cases where users want to store engine-specific functions and I think we have to support it. We are planning to implement this using a property to enable non-portable functions that are outside of the SQL and Iceberg sets. And even then, we don't expect all implementations to be able to apply all of the functions from the SQL spec. The principle we're applying here is to nudge toward interoperability and compatibility, but not force it and limit the effectiveness of the features.

wgtmac · 2026-06-25T14:53:15Z

+* `fixed` and `binary` use unsigned byte-wise comparison
+* `string` uses unsigned byte-wise comparison of the UTF-8 representation; it is not the Unicode Collation Algorithm
+* `uuid` uses unsigned byte-wise comparison of the UUID bytes
+* `decimal` uses signed comparison independent of scale; this is equivalent to comparison of unscaled values because type alignment produces values with the same scale


Not a native speaker but the phrase "independent of scale" seems to contradict "with the same scale". This might confuse developers.

This is saying that type alignment produces the same scale, so they are equivalent.

amogh-jahagirdar · 2026-06-25T14:42:10Z

+Functions are referenced using a catalog and a function identifier (list of strings).
+
+* The function identifier consists of 0 or more namespace names followed by the function name. At least one part, the function name, is required.
+* Catalog is optional and is assumed to be the catalog in which the referencing object is stored if it is not present or is null


Would it be better to require ommitting the catalog in those cases instead of having readers also to consider the explicit null case?

I don't think so. I think we don't want to need to later define how to handle a null catalog. I would rather just specify that they are the same thing.

amogh-jahagirdar · 2026-06-25T14:49:55Z

+
+* `if_else(condition: predicate, when_true: T, when_false: T) -> T`: returns the value of `when_true` when `condition` is true and `when_false` otherwise
+
+### Partition transforms


Does having partition transforms here as well as in the main spec put us in a position where any changes to these specs have to make 2 updates? Or are we planning on removing it from the main page as well?

Also on that note, I think we're missing multi-argument transforms here.

These are the corresponding functions. I think we will want to find a good way to keep these in sync, but I didn't want to remove things from the table spec as part of this change. I do think it would be reasonable to move some of those definitions here.

For multi-arg transforms, that is purely a table spec concept. These are functions, some of which take two args, but these do not define source-id or source-ids. I think we will want to define the functions here and then map the transform serialization into arguments to these functions.

amogh-jahagirdar · 2026-06-25T14:55:42Z

+Value expressions can be one of three types: a constant value, a field reference, or a function applied to zero or more value expressions.
+
+
+#### Constant values


very minor, we may just want to consistently use one term throughout this. I think everyone understands constants and literals are the same but since grammars tend to be pedantic, may just be better off sticking to one term.

My rationale is that "constant" is more clear for the purpose of the spec, but "literal" is used in expression libraries. They are basically synonyms so I thought that it was fine to use both. It is okay for implementations to continue using "literal" for constants.

I like using "constant" because the reader knows what it is and how it interacts with functions, without bringing in the questions like "what literal forms are allowed?"

amogh-jahagirdar · 2026-06-25T14:57:54Z

+EXPR: LITERAL | REFERENCE | APPLY
+
+LITERAL: VALUE
+    | { "type": "literal", "value": VALUE }


In the new grammar do we still want to allow untyped literals? I understand we may need to do it for compatibility reasons but I was under the impression here we'd deprecate producing the untyped one (so DEPRECATED_LITERAL, and then the new one with data-type. I'm mostly a bit concerned about avoiding interpretability issues of literals and producing an explicit Iceberg type doesn't seem like a significant burden? Unless there are cases where it's not reasonably known?

I think it is fine to do this, since the values are still going to be bound to align types at runtime.

singhpk234

LGTM, thanks @rdblue !

singhpk234 · 2026-06-25T17:39:17Z

+
+Field references may be named references (unbound) or ID references (bound). ID references identify a field by field ID from a schema. Named references identify a field by name that must be resolved to an ID (bound to a schema) to access the field.
+
+ID references are used for stored expressions, where the identity of the column is determined when the stored expression is created. For example, column constraints are tied to field IDs so that renaming a column does not invalidate the reference in its stored constraint.


[orthogonal] : it would be nice to have IDReference in the rest yaml too

Yes, we will add this when we update the yaml.

singhpk234 · 2026-06-25T17:52:29Z

+The context in which an expression is used determines the type of references that are valid. Iceberg specifications should document whether ID references, named references, or both are allowed.
+
+
+#### Apply function


optional: should we add a restriction that if engines is unable resolve the function, lets say the function deleted or no longer exists in catalog, MUST fail execution ?

I think that this is dependent on the context and should be specified. For example, we state in the table spec that unknown partition transforms should be ignored, rather than causing reads to fail. That was added specifically to create the ability to add new partition transforms without breaking forward-compatibility. Adding a blanket rule here would conflict with those decisions to I think these cases should be decided by the context where an expression is used or stored.

rdblue · 2026-06-29T21:20:25Z

I'm going to commit this since the vote passed and I've addressed the latest comments, which were mostly minor clarifications or updates.

This can continue to evolve, and in particular it sounds like we may want to formalize the JSON grammar. Right now it is descriptive, but not exact. For example, @stevenzwu points out that identifiers that are "one or more" names are represented with [ NAME* ] instead of [ NAME+ ].

Spec: Add spec for expressions.

111be91

github-actions Bot added the Specification Issues that may introduce spec changes. label Jun 2, 2026

wombatu-kun mentioned this pull request Jun 2, 2026

CI: Retry Trivy scanner image pull to absorb transient Docker Hub timeouts #16660

Merged

singhpk234 self-requested a review June 2, 2026 16:22

singhpk234 reviewed Jun 2, 2026

View reviewed changes

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

danielcweeks reviewed Jun 3, 2026

View reviewed changes

Comment thread format/expressions-spec.md

RussellSpitzer reviewed Jun 4, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

RussellSpitzer reviewed Jun 4, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

RussellSpitzer reviewed Jun 4, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

RussellSpitzer reviewed Jun 4, 2026

View reviewed changes

RussellSpitzer reviewed Jun 5, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

RussellSpitzer reviewed Jun 5, 2026

View reviewed changes

Comment thread format/expressions-spec.md

stevenzwu reviewed Jun 5, 2026

View reviewed changes

amogh-jahagirdar self-requested a review June 9, 2026 20:15

rdblue added 3 commits June 11, 2026 17:05

Update from review feedback.

46d65dd

More updates from reviews.

c35cd42

Add references.

d357393

stevenzwu approved these changes Jun 12, 2026

View reviewed changes

RussellSpitzer reviewed Jun 23, 2026

View reviewed changes

rdblue added 2 commits June 24, 2026 15:20

Update NaN handling and relocate some chunks to make more sense.

4f73422

Minor updates.

ebd2ff0

stevenzwu approved these changes Jun 25, 2026

View reviewed changes

szehon-ho approved these changes Jun 25, 2026

View reviewed changes

manuzhang reviewed Jun 25, 2026

View reviewed changes

wgtmac reviewed Jun 25, 2026

View reviewed changes

Comment thread format/expressions-spec.md

amogh-jahagirdar reviewed Jun 25, 2026

View reviewed changes

wgtmac reviewed Jun 25, 2026

View reviewed changes

Comment thread format/expressions-spec.md

singhpk234 approved these changes Jun 25, 2026

View reviewed changes

manuzhang mentioned this pull request Jun 26, 2026

Add mumbling-spec and expression-spec to website #16968

Open

3 tasks

huaxingao reviewed Jun 27, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

huaxingao approved these changes Jun 27, 2026

View reviewed changes

aihuaxu approved these changes Jun 28, 2026

View reviewed changes

Comment thread format/expressions-spec.md Outdated

Comment thread format/expressions-spec.md

Minor updates and clarifications.

a81282c

rdblue merged commit a2fb64b into apache:main Jun 29, 2026
8 checks passed

jakelong95 pushed a commit to jakelong95/iceberg that referenced this pull request Jun 29, 2026

Spec: Add spec for expressions (apache#16652)

5ac7f37

nssalian added this to the Iceberg 1.12.0 milestone Jul 6, 2026

manuzhang mentioned this pull request Jul 7, 2026

Spec: Clarify boolean predicate constants #17120

Open

Kurtiscwright pushed a commit to Kurtiscwright/iceberg that referenced this pull request Jul 7, 2026

Spec: Add spec for expressions (apache#16652)

0abf3ab

		\| `IS NULL` \| any \| \| true iff the value is null \|
		\| `IS NOT NULL` \| any \| \| true iff the value is not null \|

		A constant or literal is the simplest type of value expression that represents a specific typed value.


		#### Field reference


		A value expression's type is determined when it is bound to a specific input schema.

		If types are incompatible at runtime, implementations binding or evaluating expressions may apply type promotion to align types for predicates and to resolve functions. Implementations may choose when to promote values to accomodate engines that differ in casting behavior. However, implementations must fail rather than insert "unsafe" casts.


		This approach is intended to keep focus on the logical structure of expressions. Complexity is pushed to the functions that are called, which can be a limited set of well-defined and portable functions (like Iceberg partition transforms) or could be user-defined functions that can use the full range of SQL capabilities. Multi-dialect UDFs are responsible for any SQL constructs that are specific to an engine, rather than importing and duplicating dialects in Iceberg expressions.

		This is consistent with Iceberg's conservative approach in other specs. Expressions and predicates are an important part of Iceberg implementation APIs, but have been deliberately limited in specifications. For example, sort orders and partition fields are strictly limited to a small set of transforms over well-defined inputs (source field IDs). This spec is widening what can be expressed, but depends on function calls for complex tasks.


		Engines may document and use a catalog name to identify their built-in functions that are not part of the SQL spec, like `spark_builtin_functions.to_utc_timestamp`.

		Producers are responsible for resolving catalog, namespace, and name if the environment is relevant. For example, if a SQL engine uses its current catalog and namespace to find a function, the resolved catalog and namespace must be used to produce an unambiguous function identifier.


		Predicates can be constants (true or false), comparisons or tests of value expressions, or logical combinations of predicates (AND, OR, NOT).

		If value expression types in a predicate are incompatible, implementations should align types using type promotion. For instance, `int_col > 5.0` should promote int values to float. If the types cannot be aligned according to type promotion rules, the predicate must evaluate to false. For instance, `"goats" > -Infinity` should always be `false`.


		Functions are referenced using a catalog and a function identifier (list of strings).

		* The function identifier consists of 0 or more namespace names followed by the function name. At least one part, the function name, is required.

	TrueExpression:
	type: object
	required:
	- type
	properties:
	type:
	$ref: '#/components/schemas/ExpressionType'
	const: "true"

	FalseExpression:
	type: object
	required:
	- type
	properties:
	type:
	$ref: '#/components/schemas/ExpressionType'
	const: "false"


		Function calls may produce different types when function definitions change, and type changes may change the definition that is resolved for a function name. For example, if the input field passed to `identity(int) -> int` is promoted from `int` to `long`, the resolved `identity` function can change to `identity(long) -> long` if it is defined.

		If types are incompatible at runtime, implementations binding or evaluating expressions may apply type promotion to align types for predicates and to resolve functions. Implementations may choose when to promote values to accommodate engines that differ in casting behavior. However, implementations must fail rather than insert unsafe casts.


		* `if_else(condition: predicate, when_true: T, when_false: T) -> T`: returns the value of `when_true` when `condition` is true and `when_false` otherwise

		### Partition transforms

		Value expressions can be one of three types: a constant value, a field reference, or a function applied to zero or more value expressions.


		#### Constant values


		Field references may be named references (unbound) or ID references (bound). ID references identify a field by field ID from a schema. Named references identify a field by name that must be resolved to an ID (bound to a schema) to access the field.

		ID references are used for stored expressions, where the identity of the column is determined when the stored expression is created. For example, column constraints are tied to field IDs so that renaming a column does not invalidate the reference in its stored constraint.

		The context in which an expression is used determines the type of references that are valid. Iceberg specifications should document whether ID references, named references, or both are allowed.


		#### Apply function

Uh oh!

Conversation

rdblue commented Jun 2, 2026

Uh oh!

singhpk234 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rdblue Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rdblue Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

rdblue Jun 23, 2026 •

edited

Loading

rdblue Jun 24, 2026 •

edited

Loading

szehon-ho commented Jun 25, 2026 •

edited

Loading

manuzhang Jul 7, 2026 •

edited

Loading