| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org |
| Subject: | Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take) |
| Date: | 2017-05-19 22:43:08 |
| Message-ID: | CAEepm=2BZf-KD3WuUaA1kHvvDM0quaWgMjNcjBdGKXZDc6arSw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Thomas Munro
http://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| transition-tuples-from-child-tables-v8.patch | application/octet-stream | 59.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-05-19 23:06:07 | Re: TAP tests - installcheck vs check |
| Previous Message | Petr Jelinek | 2017-05-19 22:10:21 | Re: Multiple table synchronizations are processed serially |