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?
--
Thomas Munro
http://www.enterprisedb.com