That sort of thing can be handled by the client, though (and note it says that the error is if the statement is closed, not finished). So it doesn't seem strictly necessary, though it would allow a client to express intent.
On Fri, Jun 23, 2023, at 13:25, Weston Pace wrote: > One small difference seems to be that Close is idempotent and Cancel is not. > >> void cancel() >> throws SQLException >> >> Cancels this Statement object if both the DBMS and driver support > aborting an SQL statement. This method can be used by one thread to cancel > a statement that is being executed by another thread. >> >> Throws: >> SQLException - if a database access error occurs or this method is > called on a closed Statement > > In other words, with cancel, you can display an error to the user if the > statement is already finished (and thus was not able to be canceled). > However, I don't know if that is significant at all. > > On Fri, Jun 23, 2023 at 12:17 AM Sutou Kouhei <k...@clear-code.com> wrote: > >> Hi, >> >> Thanks for sharing your thoughts. >> >> OK. I'll change the current specifications/implementations >> to the followings: >> >> * Remove CloseFlightInfo (if nobody objects it) >> * RefreshFlightEndpoint -> >> RenewFlightEndpoint >> * RenewFlightEndpoint(FlightEndpoint) -> >> RenewFlightEndpoint(RenewFlightEndpointRequest) >> * CancelFlightInfo(FlightInfo) -> >> CancelFlightInfo(CancelFlightInfoRequest) >> >> >> Thanks, >> -- >> kou >> >> In <CAH4123YJaP7ZKZAUmznZ0CSsdb+6tsOJzvFJGiqEd=bcwkz...@mail.gmail.com> >> "Re: [DISCUSS][Format][Flight] Result set expiration support" on Thu, 22 >> Jun 2023 12:51:55 -0400, >> Matt Topol <zotthewiz...@gmail.com> wrote: >> >> >> That said, I think it's reasonable to only have Cancel at the protocol >> > level. >> > >> > I'd be in favor of only having Cancel too. In theory calling Cancel on >> > something that has already completed should just be equivalent to calling >> > Close anyways rather than requiring a client to guess and call Close if >> > Cancel errors or something. >> > >> >> So this may not be needed for now. How about accepting a >> >> specific request message instead of FlightEndpoint directly >> >> as "PersistFlightEndpoint" input? >> > >> > I'm also in favor of this. >> > >> >> I think Refresh was fine, but if there's confusion, I like Kou's >> > suggestion of Renew the best. >> > >> > I'm in the same boat as David here, I think Refresh was fine but like the >> > suggestion of Renew best if we want to avoid any confusion. >> > >> > >> > >> > On Thu, Jun 22, 2023 at 2:55 AM Antoine Pitrou <anto...@python.org> >> wrote: >> > >> >> >> >> Doesn't protobuf ensure forwards compatibility? Why would it break? >> >> >> >> At worse, you can include the changes necessary for it to compile >> >> cleanly, without adding support for the new fields/methods? >> >> >> >> >> >> Le 22/06/2023 à 02:16, Sutou Kouhei a écrit : >> >> > Hi, >> >> > >> >> > The following part in the original e-mail is the one: >> >> > >> >> >> https://github.com/apache/arrow/pull/36009 is an >> >> >> implementation of this proposal. The pull requests has the >> >> >> followings: >> >> >> >> >> >> 1. Format changes: >> >> >> * format/Flight.proto >> >> >> >> >> >> https://github.com/apache/arrow/pull/36009/files#diff-53b6c132dcc789483c879f667a1c675792b77aae9a056b257d6b20287bb09dba >> >> >> * format/FlightSql.proto >> >> >> >> >> >> https://github.com/apache/arrow/pull/36009/files#diff-fd4e5266a841a2b4196aadca76a4563b6770c91d400ee53b6235b96da628a01e >> >> >> >> >> >> 2. Documentation changes: >> >> >> docs/source/format/Flight.rst >> >> >> >> >> >> https://github.com/apache/arrow/pull/36009/files#diff-839518fb41e923de682e8587f0b6fdb00eb8f3361d360c2f7249284a136a7d89 >> >> > >> >> > We can split the part to a separated pull request. But if we >> >> > split the part and merge the pull requests for format >> >> > related changes and implementation related changes >> >> > separately, our CI will be broken temporary. Because our >> >> > implementations use auto-generated sources that are based on >> >> > *.proto. >> >> > >> >> > >> >> > Thanks, >> >> >>
