Hi, On Sun, Aug 4, 2019 at 3:03 AM Andres Freund <and...@anarazel.de> wrote: > On 2019-08-03 13:48:01 -0400, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > On 2019-08-03 19:41:55 +0900, Etsuro Fujita wrote: > > >> What API does that function break? > > > > > You need to call it, whereas previously you did not need to call it. The > > > effort to change an FDW to get one more parameter, or to call that > > > function is about the same.
I got the point. > > If those are the choices, adding a parameter is clearly the preferable > > solution, because it makes the API breakage obvious at compile. > > Right. I think it's a *bit* less clear in this case because we'd also > remove the field that such FDWs with direct modify support would use > now (EState.es_result_relation_info). > > But I think it's also just plainly a better API to use the > parameter. Even if, in contrast to the BeginDirectModify at hand, > BeginForeignModify didn't already accept it. Requiring a function call to > gather information that just about every realistic implementation is > going to need doesn't make sense. Agreed. Best regards, Etsuro Fujita
