On Tue, Apr 4, 2017 at 3:41 AM, Kevin Grittner <kgri...@gmail.com> wrote: > On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Thomas Munro <thomas.mu...@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
Description: Binary data
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers