On Thu, May 4, 2017 at 4:46 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera <alvherre@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 <david@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
