Thanks for bringing this up, Christian.
I double-checked the spec, specifically where we use the `metadata` and
`metadata-location` fields. My assumption is that these are the places
where we want to include etag.
For example, following the `metadata-location` field (note: the `metadata`
field overlaps with the same objects):
```
metadata-location
LoadTableResult -> LoadTableResponse / CreateTableResponse
CommitTableResponse
LoadViewResult -> LoadViewResponse
RegisterTableRequest
```
`LoadTableResponse` and `CreateTableResponse` are already covered.
`CommitTableResponse` is missing and addressed by your PR [1] and vote
thread.
We might want to add the etag field to `LoadViewResponse`.
And `RegisterTableRequest` can be ignored since it's a request object.
Let me know what you think about adding etag to `LoadViewResponse`.
Best,
Kevin Liu
[1] https://github.com/apache/iceberg/pull/14760
On Fri, Dec 5, 2025 at 8:03 AM John Zhuge <[email protected]> wrote:
> Make sense
>
> John Zhuge
>
>
> On Thu, Dec 4, 2025 at 11:19 PM huaxin gao <[email protected]> wrote:
>
>> +1
>>
>> On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner <
>> [email protected]> wrote:
>>
>>> Makes sense to add this, so +1
>>>
>>> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <[email protected]> wrote:
>>>
>>>> +1. There’s no known reason to exclude it, adding the ETag to
>>>> CommitTableResponse feels like a natural and consistent extension of the
>>>> existing behavior.
>>>>
>>>> Yufei
>>>>
>>>>
>>>> On Thu, Dec 4, 2025 at 8:33 AM Christian Thiel <
>>>> [email protected]> wrote:
>>>>
>>>>> Hey Gábor,
>>>>> Thanks for the Feedback! I'll give it another day for others to chime
>>>>> in and otherwise start the vote.
>>>>> I am currently at a point where I need it in Rust and was surprised it
>>>>> wasn't there :)
>>>>>
>>>>> Best,
>>>>> Christian
>>>>>
>>>>> On Thu, 4 Dec 2025 at 16:39, Gábor Kaszab <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Christian,
>>>>>>
>>>>>> There is no particular reason ETag is not included in the
>>>>>> CommitTableResponse in the spec. In fact the reference IRC already
>>>>>> returns
>>>>>> ETag on that endpoint. I also had it in mind to extend the spec with
>>>>>> this,
>>>>>> I just wanted to finish the implementation of using ETags on the client
>>>>>> side for the loadTable endpoint (side note, it's open for review
>>>>>> <https://github.com/apache/iceberg/pull/14398>, any feedback is
>>>>>> appreciated!). In terms of implementation, it is not that trivial to
>>>>>> implement the usage of the ETag after a RESTTableOperations.commit() /
>>>>>> refresh(), but this is another story, just the reason I wasn't in a rush
>>>>>> extending the ETag support further in the REST spec.
>>>>>>
>>>>>> Long story short, I'm +1 on this!
>>>>>> Gabor
>>>>>>
>>>>>> Christian Thiel <[email protected]> ezt írta (időpont:
>>>>>> 2025. dec. 4., Cs, 16:00):
>>>>>>
>>>>>>> Dear all,
>>>>>>> I noticed that we currently don't return an etag after single table
>>>>>>> commits.
>>>>>>> As of now, etags are returned for CreateTableResponse and
>>>>>>> LoadTableResponse. I browsed the original doc [1], the PR [2], the
>>>>>>> mailing
>>>>>>> List and my brain but couldn't find a discussion around this.
>>>>>>>
>>>>>>> Is anyone aware of a reason why we didn't include
>>>>>>> CommitTableResponse?
>>>>>>> If not I would start a vote on [3] to include it.
>>>>>>>
>>>>>>> Best,
>>>>>>> Christian
>>>>>>>
>>>>>>> [1]
>>>>>>> https://docs.google.com/document/d/1rnVSP_iv2I47giwfAe-Z3DYhKkKwWCVvCkC9rEvtaLA
>>>>>>> [2] https://github.com/apache/iceberg/pull/11946
>>>>>>> [3] https://github.com/apache/iceberg/pull/14760
>>>>>>>
>>>>>>>
