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  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: partition routing layering in nodeModifyTable.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions