Conversation
Consolidate versioned operation tables, track v3-specific capabilities, and refresh implementation status across language libraries. Generated-by: Codex Co-authored-by: Codex <codex@openai.com>
f253b68 to
6cb25c8
Compare
Present version-independent capabilities in a shared table and use open-ended version notation where features continue beyond their introduction.\n\nGenerated-by: Codex
Record the released library versions used by the status page and remove capability claims that depend on unreleased commits.\n\nGenerated-by: Codex
Identify data types by the format version that introduced them while preserving the existing libraries introduction.\n\nGenerated-by: Codex
Place the shared Spec column explanation before the first status table that uses it.\n\nGenerated-by: Codex
|
I think it's definitely good to add this information but i'm not quite sure about the format. Did we just not to copy the compatibility section for V3? Having multiple roles for support based on the version seems a little harder to read imho. |
I think it will be easier to compare between versions. With more versions incoming, it's hard to maintain them copying almost identical table every time. |
| | uuid | V1+ | Y | Y | Y | Y | N | | ||
| | fixed | V1+ | Y | Y | Y | Y | Y | | ||
| | binary | V1+ | Y | Y | Y | Y | Y | | ||
| | variant | V3+ | Y | Y | N | Y | N | |
There was a problem hiding this comment.
this isn't right. variant is only supported in java, rust, go. python is pending. c++ is pending as well, that's rightly marked here
There was a problem hiding this comment.
Thanks for catching this. I will do another round of review.
|
|
||
| ## Table Maintenance Operations | ||
|
|
||
| ### Table Spec V1 |
There was a problem hiding this comment.
This seems easier to read for a user. We could combine like the PR does but keeping it this way (per version) tells a user what to expect in each version rather than infer from one Spec version column. Combining does make it leaner but I don't know if that really matters, I'd lean on simplicity.
Correct type support for PyIceberg, Go, and C++, and mark C++ V3 metadata and row-lineage writes according to the 0.3.0 release. Generated-by: Codex Co-authored-by: Codex <codex@openai.com>
f1c6d5e to
1ef76e3
Compare
|
@RussellSpitzer @nssalian I'm using tabbed table now. Each Table Spec gets its own tab or one merged tab if their contents are identical. |
1ef76e3 to
b02246d
Compare
There was a problem hiding this comment.
nit: is there a way to not override the template? Curious why need extra logic here
b02246d to
d8a2258
Compare
58cea0a to
b7de469
Compare
Correct released-library status and distinguish REST-dependent V3 metadata maintenance from local catalog writes. Require schema and value read/write support for Data Types Y, and mark schema-only geospatial support N. Preserve combined-version tabs and original heading levels with default theme behavior. Generated-by: Codex Co-authored-by: Codex <codex@openai.com>
b7de469 to
3b666b3
Compare
This branch has not been deployed
4 participants
Summary
Yas schema support plus both value reads and writes in a supported data file format; mark Java and PyIceberg geometry/geographyNbecause schema recognition alone is insufficientV1 - V2andV1 - V3Table Specsubtitles at their original heading levelsCloses #17308.
Audit scope
Published releases audited, with review findings rechecked on 2026-09-22:
6976e020b875396614a504ae06bdb1350ae7270d0284683f7eTesting
git diff --checkmake -C site lint.venv/bin/python3 -m mkdocs buildwrite_fileandArrowScan; geometry/geography inputs fail schema compatibility with both GeoArrow extensions and binary fallbackAI Disclosure