Re: Add CREATE support to event triggers
От | Simon Riggs |
---|---|
Тема | Re: Add CREATE support to event triggers |
Дата | |
Msg-id | CA+U5nMJWcqvgA50aTyoB40FK+GdgsmV=BHSva+qU-mFQL7uGRg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add CREATE support to event triggers (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On 10 January 2014 23:22, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > On the subject of testing the triggers, Robert Haas wrote: > >> Here's one idea: create a contrib module that (somehow, via APIs to be >> invented) runs every DDL command that gets executed through the >> deparsing code, and then parses the result and executes *that* instead >> of the original command. Then, add a build target that runs the >> regression test suite in that mode, and get the buildfarm configured >> to run that build target regularly on at least some machines. That >> way, adding syntax to the regular regression test suite also serves to >> test that the deparsing logic for that syntax is working. If we do >> this, there's still some maintenance burden associated with having DDL >> deparsing code, but at least our chances of noticing when we've failed >> to maintain it should be pretty good. > > I gave this some more thought and hit a snag. The problem here is that > by the time the event trigger runs, the original object has already been > created. At that point, we can't simply replace the created objects > with objects that would hypothetically be created by a command trigger. Yes, all we are doing is firing a trigger that has access to the information about the current object. > A couple of very hand-wavy ideas: > > 1. in the event trigger, DROP the original object and CREATE it as > reported by the creation_commands SRF. > > 2. Have ddl_command_start open a savepoint, and then roll it back in > ddl_command_end, then create the object again. Not sure this is doable > because of the whole SPI nesting issue .. maybe with C-language event > trigger functions? We need to be clear what action we are testing exactly. Once we know that we can come up with a test mechanism. We can come up with various tests that test coverage but that may not be enough. Mostly we're just splitting up fields from the DDL, like object name into its own text field, as well as augmenting it with database name. That's pretty simple and shouldn't require much testing. This code seems likely to be prone to missing features much more so than actual bugs. Missing a piece of useful information in the JSON doesn't mean there is a bug. If all the event trigger does is generate JSON, then all we need to do is test that the trigger fired and generated well-formed JSON with the right information content. That should be very simple and I would say the simpler the better. To do that we can run code to parse the JSON and produce formatted text output like this... Field | Value ---------+----------- XX afagaha YY aamnamna The output can be derived from visual inspection, proving that we generated the required JSON. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: