Re: Update does not move row across foreign partitions in v11

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Update does not move row across foreign partitions in v11
Дата
Msg-id 5C810FF7.8010802@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Update does not move row across foreign partitions in v11  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Update does not move row across foreign partitions in v11
Re: Update does not move row across foreign partitions in v11
Список pgsql-hackers
(2019/03/06 15:34), Amit Langote wrote:
> On 2019/03/06 15:10, Etsuro Fujita wrote:
>> --- a/doc/src/sgml/ddl.sgml
>> +++ b/doc/src/sgml/ddl.sgml
>> @@ -3376,6 +3376,13 @@ ALTER TABLE measurement ATTACH PARTITION
>> measurement_y2008m02
>>         </para>
>>        </listitem>
>>
>> +<listitem>
>> +<para>
>> +<command>UPDATE</command>  row movement is not supported in the cases
>> +       where the old row is contained in a foreign table partition.
>> +</para>
>> +</listitem>
>>
>> ISTM that it's also a limitation that rows can be moved from a local
>> partition to a foreign partition *if the FDW support tuple routing*, so I
>> would vote for mentioning that as well here.
>
> Thanks for checking.
>
> I have updated the patch to include a line about this in the same
> paragraph, because maybe we don't need to make a new<listitem>  for it.

Thanks for the patch!

The patch looks good to me, but one thing I'm wondering is: as suggested 
by David, it would be better to rephrase this mention in the UPDATE 
reference page, in a single commit:

"Currently, rows cannot be moved from a partition that is a foreign 
table to some other partition, but they can be moved into a foreign 
table if the foreign data wrapper supports it."

I don't think it needs to be completely rephrased; it's enough for me to 
rewrite it to something like this:

"Currently, rows cannot be moved from a foreign-table partition to some 
other partition, but they can be moved into a foreign-table partition if 
the foreign data wrapper supports tuple routing."

And to make maintenance work easy, I think it might be better to just 
put this on the limitations section of 5.10. Table Partitioning.  What 
do you think about that?

Best regards,
Etsuro Fujita



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexey Kondratov
Дата:
Сообщение: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_dump multi VALUES INSERT