RE: extension patch of CREATE OR REPLACE TRIGGER - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: extension patch of CREATE OR REPLACE TRIGGER
Date
Msg-id OSBPR01MB48883C847E6E2C048FB22EF7EDEA0@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: extension patch of CREATE OR REPLACE TRIGGER  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: extension patch of CREATE OR REPLACE TRIGGER
List pgsql-hackers
Hi,


On Saturday, Nov 7, 2020 2:06 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> The patch looks fine to me however I feel that in the test case there are a lot
> of duplicate statement which can be reduced e.g.
> +-- 1. Overwrite existing regular trigger with regular trigger
> (without OR REPLACE)
> +create trigger my_trig
> +  after insert on my_table
> +  for each row execute procedure funcA(); create trigger my_trig
> +  after insert on my_table
> +  for each row execute procedure funcB(); -- should fail drop trigger
> +my_trig on my_table;
> +
> +-- 2. Overwrite existing regular trigger with regular trigger (with OR
> +REPLACE) create trigger my_trig
> +  after insert on my_table
> +  for each row execute procedure funcA(); insert into my_table values
> +(1); create or replace trigger my_trig
> +  after insert on my_table
> +  for each row execute procedure funcB(); -- OK insert into my_table
> +values (1); drop trigger my_trig on my_table;
> 
> In this test, test 1 failed because it tried to change the trigger function without
> OR REPLACE, which is fine but now test 2 can continue from there, I mean we
> don't need to drop the trigger at end of the
> test1 and then test2 can try it with OR REPLACE syntax.  This way we can
> reduce the extra statement execution which is not necessary.
OK. That makes sense.

Attached the revised version.
The tests in this patch should not include redundancy.
I checked the tests of trigger replacement for partition tables as well.

Here, I did not and will not delete the comments with numbering from 1 to 8 so that
other developers can check if the all cases are listed up or not easily.


Best,
    Takamichi Osumi

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Some doubious code in pgstat.c
Next
From: Andy Fan
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans