Re: partition routing layering in nodeModifyTable.c
От | Andres Freund |
---|---|
Тема | Re: partition routing layering in nodeModifyTable.c |
Дата | |
Msg-id | 20190803180341.vhwxn6zlqkhckr5m@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: partition routing layering in nodeModifyTable.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: partition routing layering in nodeModifyTable.c
|
Список | pgsql-hackers |
Hi, On 2019-08-03 13:48:01 -0400, Tom Lane wrote: > Andres Freund <andres@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. > > 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: