Re: Remove mention in docs that foreign keys on partitioned tablesare not supported

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Дата
Msg-id CAFjFpRdBQiGOxtSURpXLwskK6GTn_uROP9_JOBN3EB80RCEzag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Remove mention in docs that foreign keys on partitioned tablesare not supported  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Remove mention in docs that foreign keys on partitioned tablesare not supported  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, May 2, 2018 at 11:56 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> But one could very well argue that BEFORE ROW triggers on the
> parent should run before performing the tuple routing and not be cloned to
> individual partitions, in which case the result would not have been the
> same.  Perhaps that's the motivation behind leaving this to be considered
> later.

+1 for that. We should associate before row triggers with the
partitioned table and not with the partitions. Those should be
executed before tuple routing (for that partition level) kicks in. But
then that would be asymetric with AFTER row trigger behaviour. From
this POV, pushing AFTER row triggers to the individual partitions
doesn't look good.

Other question that comes to my mind is what happens when rows are
inserted into a partition directly. Do we execute BEFORE trigger on
the partitioned table?

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


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

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: inconsistency and inefficiency in setup_conversion()
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Should we add GUCs to allow partition pruning to be disabled?