aokolnychyi commented on a change in pull request #2654:
URL: https://github.com/apache/iceberg/pull/2654#discussion_r651436461
##########
File path: site/docs/spec.md
##########
@@ -176,6 +178,15 @@ Columns in Iceberg data files are selected by field id.
The table schema's colum
For example, a file may be written with schema `1: a int, 2: b string, 3: c
double` and read using projection schema `3: measurement, 2: name, 4: a`. This
must select file columns `c` (renamed to `measurement`), `b` (now called
`name`), and a column of `null` values called `a`; in that order.
+#### Identifier Field IDs
+
+A schema can optionally track the set of primitive fields that identify rows
in a table, using the property `identifier-field-ids` (see JSON encoding in
Appendix C).
+
+Two rows are the "same"---that is, the rows represent the same entity---if the
identifier fields are equal. However, uniqueness of rows by this identifier is
not guaranteed or required by Iceberg because it is needlessly inefficient in
some cases. Reasonable steps to enforce uniqueness are the responsibility of
processing engines.
+
+Optional fields can be used as identifier fields. Identifier fields may be
nested in structs but may not be nested within maps or lists; a nested
identifier field is considered null if it or any parent struct is null. For
identifier comparison, null is considered equal to itself.
Review comment:
This seems a bit controversial as columns in a primary key are never
nullable (even though identity fields are not technically a primary key) and
null is never equal to null in SQL.
Would it be reasonable to follow the SQL standard and require the identity
columns as well as columns used in equality deletes be always not null? My
worry is that it is going to be tricky if we interpret this differently from
SQL. What if I upsert by (1, 'a', null)? I think that row should match nothing
from the SQL perspective.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
