Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On 2017/05/20 9:01, Thomas Munro wrote:
> On Sat, May 20, 2017 at 10:43 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> On Fri, May 19, 2017 at 6:35 PM, Amit Langote
>> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> On 2017/05/19 15:16, Thomas Munro wrote:
>>>> Would TransitionCaptureState be a better name for this struct?
>>>
>>> Yes. Although, losing the Trigger prefix might make it sound a bit
>>> ambiguous though. Right above its definition, we have TriggerData. So,
>>> maybe TriggerTransitionCaptureState or TriggerTransitionCaptureData or
>>> TriggerTransitionData may be worth considering.
>>
>> Ok, here's a version using TransitionCaptureState. Those other names
>> seem too long, and "TriggerTransition" is already in use so
>> "TriggerTransitionData" seems off the table. Having the word
>> "capture" in there seems good, since this is an object that controls
>> what we capture when we process a modify a set of tables. I hope
>> that's clear.

I agree. TransitionCaptureState sounds good.

> Sent too soon. Several variables should also be renamed to make clear
> they refer to the transition capture state in effect, instead of vague
> names like 'transitions'. Sorry for the version churn.

Ah, I was kind of getting distracted by it earlier too; thanks.

Anyway, the patch looks good to me.

Thanks,
Amit