On 2017/04/28 7:36, David Fetter wrote: > On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote: >> On 2017/04/27 1:52, Robert Haas wrote: >>> On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote >>> <langote_amit...@lab.ntt.co.jp> wrote: >>>> FWIW, I too prefer the latter, that is, fire only the parent's triggers. >>>> In that case, applying only the patch 0001 will do. >>> >>> Do we need to update the documentation? >> >> Yes, I think we should. How about as in the attached? >> >> By the way, code changes I made in the attached are such that a subsequent >> patch could implement firing statement-level triggers of all the tables in >> a partition hierarchy, which it seems we don't want to do. Should then >> the code be changed to not create ResultRelInfos of all the tables but >> only the root table (the one mentioned in the command)? You will see that >> the patch adds fields named es_nonleaf_result_relations and >> es_num_nonleaf_result_relations, whereas just es_root_result_relation >> would perhaps do, for example. > > Did I notice correctly that there's no way to handle transition tables > for partitions in AFTER STATEMENT triggers?
Did you mean to ask about AFTER STATEMENT triggers defined on "partitioned" tables? Specifying transition table for them is disallowed at all. ERROR: "p" is a partitioned table DETAIL: Triggers on partitioned tables cannot have transition tables. Triggers created on (leaf) partitions *do* allow specifying transition table. Or are you asking something else altogether? > If not, I'm not suggesting that this be added at this late date, but > we might want to document that. I don't see mentioned in the documentation that such triggers cannot be defined on partitioned tables. Is that what you are saying should be documented? Thanks, Amit -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers