Re: delta relations in AFTER triggers
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Kevin Grittner <kgrittn@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Haribabu Kommi <kommi.haribabu@gmail.com>,
Jim Nasby <Jim.Nasby@bluetreble.com>, Craig Ringer <craig@2ndquadrant.com>,
Michael Paquier <michael.paquier@gmail.com>, David Fetter <david@fetter.org>, Kevin Grittner <kgrittn@ymail.com>, Amit Khandekar <amit.khandekar@enterprisedb.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-04-04T00:16:06Z
Lists: pgsql-hackers
Attachments
- transition-tables-for-all.patch (application/octet-stream) patch
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
Commits
-
Don't permit transition tables with TRUNCATE triggers.
- 29fd3d9da0ff 10.0 landed
-
Pass EXEC_FLAG_REWIND when initializing a tuplestore scan.
- 304007d9f1f6 10.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited
-
Remove obsoleted code relating to targetlist SRF evaluation.
- ea15e18677fc 10.0 cited
-
Implement syntax for transition tables in AFTER triggers.
- 8c48375e5f43 10.0 cited