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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to