I think it makes sense to deprecate any APIs which end up writing position deletes with row values. I'm not sure how much it's worth from a spec perspective to go and mark that field as deprecated. I'm not opposed to it since it does clearly indicate the community stance, but since subsequent format versions are anyways using DVs, I don't know how much of a difference it makes.
Like Renjie mentioned, I think an implementation notes detail indicating that there are no known producers of the row data and that the reference implementation is dropping support for that in 2.0 would go a long way in preventing any further proliferation of those types of position deletes. Thanks, Amogh Jahagirdar On Tue, Aug 19, 2025 at 8:23 PM Renjie Liu <liurenjie2...@gmail.com> wrote: > I think it would make sense to mention that it's deprecated in > implementation notes. Some libraries such as iceberg-rust are currently > working on v2 support, and if we have that statement in spec we could > ignore the support of row data in position deletes. > > On Wed, Aug 20, 2025 at 12:53 AM Russell Spitzer < > russell.spit...@gmail.com> wrote: > >> Sorry! I meant to say also that I am fully in favor of completely >> removing/deprecating this. But since we deprecated Position Deletes in V3 >> we probably >> already have this covered? >> >> On Tue, Aug 19, 2025 at 11:06 AM Fokko Driesprong <fo...@apache.org> >> wrote: >> >>> PyIceberg doesn't produce it, or uses it at the planning phase. Curious >>> if there is any library that actually uses this. >>> >>> I do agree with Russell, and maybe deprecating this at the spec >>> level makes more sense. >>> >>> Kind regards, >>> Fokko >>> >>> Op di 19 aug 2025 om 17:54 schreef Russell Spitzer < >>> russell.spit...@gmail.com>: >>> >>>> I'm not sure we can deprecate the column in a library version update, >>>> but currently it is marked as optional >>>> and I don't think the Apache Java Library even has a way of writing or >>>> reading them. >>>> >>>> On Tue, Aug 19, 2025 at 10:15 AM Péter Váry < >>>> peter.vary.apa...@gmail.com> wrote: >>>> >>>>> During the last community sync (30/07), we discussed the current state >>>>> of the File Format API proposal [1] and found that implementing the >>>>> writers >>>>> for Positional Deletes where the actual row data is provided would >>>>> complicate things quite a bit. >>>>> >>>>> The current Iceberg V2 spec [2] defines two types of position delete >>>>> files: >>>>> >>>>> 1. Files that store only the file name and row position. >>>>> 2. Files that also store the deleted row data. >>>>> >>>>> The 1st type of the position deletes are widely used. The 2nd type of >>>>> deletes is defined in the spec and some tests exist in the Iceberg >>>>> codebase, but we’re not aware of any actual implementation using the >>>>> second >>>>> type (position delete files with row data). Supporting writing V2 tables >>>>> via the new File Format API would be simpler if we dropped support for >>>>> this >>>>> feature. >>>>> >>>>> I would like to hear of any uses of these delete files. If we can not >>>>> find use-cases, then *I propose to deprecate position delete files >>>>> with embedded row data starting from Iceberg 2.0.* >>>>> >>>>> Thanks, >>>>> Peter >>>>> >>>>> [1] - https://lists.apache.org/thread/ovyh52m2b6c1hrg4fhw3rx92bzr793n2 >>>>> [2] - Position Delete File Spec: >>>>> https://iceberg.apache.org/spec/?h=delete#position-delete-files >>>>> >>>>
