[
https://issues.apache.org/jira/browse/CALCITE-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697586#comment-17697586
]
Julian Hyde commented on CALCITE-5558:
--------------------------------------
Would this be a breaking change?
Update count never needs to be negative (except perhaps to store a 'not
specified' value), so I don't feel strongly about whether it is stored in a
signed or unsigned. I do acknowledge that it maps to a Java {{long}} (64 bit
signed integer).
> avatica protobuf update_count and other signed ints should not be unsigned
> --------------------------------------------------------------------------
>
> Key: CALCITE-5558
> URL: https://issues.apache.org/jira/browse/CALCITE-5558
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: avatica-1.23.0
> Reporter: Martin Jonsson
> Priority: Minor
>
> the update_count field of result set response in avatica is defined as uint64
> which by default takes negative value -1.
> The protobuf specification states that negative values should use int or
> sint, not uint, since uint is... unsigned. For this reason many protobuf
> implementations can't handle uints that are negative. This might not be a
> terrible if you are building a client but I'm building a server based on
> avatica protobuf protocol and I would like it to work not just with standard
> java implementation and c++ implementation which seems to be the ones that
> handles this odd case.
> Would it be possible to change update_count from uint64 to int64? and same
> for all other possible negative ints currently defined as unsigned?
>
> Many thanks
> Martin
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
