On Thu, May 4, 2017 at 4:46 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: >> Robert Haas wrote: >>> I suspect that most users would find it more useful to capture all of >>> the rows that the statement actually touched, regardless of whether >>> they hit the named table or an inheritance child. >> >> Yes, agreed. For the plain inheritance cases each row would need to >> have an indicator of which relation it comes from (tableoid); I'm not >> sure if such a thing would be useful in the partitioning case. > > On Thu, May 4, 2017 at 4:26 AM, David Fetter <da...@fetter.org> wrote: >> +1 on the not-duct-tape view of partitioned tables. > > Hmm. Ok. Are we talking about PG10 or PG11 here? Does this approach > makes sense?
I was thinking PG10 if it can be done straightforwardly. > 1. Remove the prohibition on creating transition-capturing triggers > on a partitioned table. > > 2. Make sure that the ExecAR* functions call AfterTriggerSaveEvent > when modifying partition tables if the explicitly named parent > partitioned table has after triggers with transition tables. Not sure > how exactly how but doesn't seem difficult. > > 3. Convert tuples to the TupleDesc of the relation that owns the > statement trigger (ie the partitioned table) when inserting them into > the tuplestore. One way to do that might be to build an array of > TupleConversionMap objects that does the opposite of the conversions > done by tup_conv_maps. While tup_conv_maps is for converting tuples > to the layout needed for a partition, tup_unconv_maps (or better name) > would be for converting the old and new tuples to the TupleDesc of the > partitioned table. Then the appropriate TupleConversionMap could be > passed into the ExecAR* functions as a new argument 'transition_map'. > AfterTriggerSaveEvent would use 'oldtup' and 'newtup' directly for ROW > triggers, but convert using the passed in map if it needs to insert > them into the transition tuplestores. > > The same thing could work for inheritance, if tupconvert.c had a new > kind of conversion that allows slicing of tuples (converting a wider > child table's tuples to the parent's subset of columns) rather the > just conversion between logically equivalent TupleDescs. > > To avoid the whiff of duct tape, we'd probably also want to make ROW > triggers created on the partitioned table(s) containing partition to > fire too, with appropriate TypeConversionMap treatment. Not sure what > exactly is involved there. > > On the other hand, doing that with inheritance hierarchies would be an > incompatible behavioural change, which I guess people don't want -- am > I right? Incompatible with what? Transition tables haven't been released yet. If we're going to fix the definition of what they do, now's the time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers