On Mon, Apr 3, 2017 at 7:16 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Apr 4, 2017 at 3:41 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
>> On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>>>> Or perhaps the code to inject trigger data transition tables into SPI
>>>> (a near identical code block these three patches) should be somewhere
>>>> common so that each PLs would only need to call a function. If so,
>>>> where should that go?
>>>
>>> spi.c?
>>
>> Until now, trigger.c didn't know about SPI, and spi.c didn't know
>> about triggers. The intersection was left to referencing code, like
>> PLs. Is there any other common code among the PLs dealing with this
>> intersection? If so, maybe a new triggerspi.c file (or
>> spitrigger.c?) would make sense. Possibly it could make sense from
>> a code structure PoV even for a single function, but it seems kinda
>> iffy for just this function. As far as I can see it comes down to
>> adding it to spi.c or creating a new file -- or just duplicating
>> these 30-some lines of code to every PL.
>
> Ok, how about SPI_register_trigger_data(TriggerData *)? Or any name
> you prefer... I didn't suggest something as specific as
> SPI_register_transition_tables because think it's plausible that
> someone might want to implement SQL standard REFERENCING OLD/NEW ROW
> AS and make that work in all PLs too one day, and this would be the
> place to do that.
>
> See attached, which add adds the call to all four built-in PLs. Thoughts?
Worked on the docs some more and then pushed it.
Nice job cutting the number of *.[ch] lines by 30 while adding support for
the other three core PLs. :-)
--
Kevin Grittner