Re: Declarative partitioning - another take
От | Amit Kapila |
---|---|
Тема | Re: Declarative partitioning - another take |
Дата | |
Msg-id | CAA4eK1LCOP5b8zjOfuCK1rXj+A-xNE8GgPgNVoofjUX3XdGLCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Declarative partitioning - another take (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Declarative partitioning - another take
Re: Declarative partitioning - another take |
Список | pgsql-hackers |
On Thu, Oct 6, 2016 at 12:44 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > On 2016/10/05 2:12, Robert Haas wrote: >> On Tue, Oct 4, 2016 at 4:02 AM, Amit Langote >> <Langote_Amit_f8@lab.ntt.co.jp> wrote: >>>> Even if we leave the empty relfilenode around for now -- in the long >>>> run I think it should die -- I think we should prohibit the creation >>>> of subsidiary object on the parent which is only sensible if it has >>>> rows - e.g. indexes. It makes no sense to disallow non-inheritable >>>> constraints while allowing indexes, and it could box us into a corner >>>> later. >>> >>> I agree. So we must prevent from the get-go the creation of following >>> objects on parent tables (aka RELKIND_PARTITIONED_TABLE relations): >>> >>> * Indexes >>> * Row triggers (?) >> >> Hmm, do we ever fire triggers on the parent for operations on a child >> table? Note this thread, which seems possibly relevant: >> >> https://www.postgresql.org/message-id/flat/cd282adde5b70b20c57f53bb9ab75e27%40biglumber.com > > The answer to your question is no. > > The thread you quoted discusses statement-level triggers and the > conclusion is that they don't work as desired for UPDATE and DELETE on > inheritance tables. As things stand, only UPDATE or DELETE on the parent > affects the child tables and it's proposed there that the statement-level > triggers on the parent and also on any child tables affected should be > fired in that case. > Doesn't that imply that the statement level triggers should be fired for all the tables that get changed for statement? If so, then in your case it should never fire for parent table, which means we could disallow statement level triggers as well on parent tables? Some of the other things that we might want to consider disallowing on parent table could be: a. Policy on table_name b. Alter table has many clauses, are all of those allowed and will it make sense to allow them? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: