On Fri, May 5, 2017 at 2:40 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
Ok, I will draft a patch to do it the way I described and see what people think.
>> 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.
The last two paragraphs of my email were about ROW triggers created on
partitioned tables and tables with inheritance children, not the new
transition table stuff. I will forget that for now and look only at
making the transition tables duct-tape-free.
--
Thomas Munro
http://www.enterprisedb.com
