Re: Unexpected behavior with transition tables in update statementtrigger
От | Tom Kazimiers |
---|---|
Тема | Re: Unexpected behavior with transition tables in update statementtrigger |
Дата | |
Msg-id | 20180227200830.ctzfnqrczzn5ijer@dewberry.localdomain обсуждение исходный текст |
Ответ на | Re: Unexpected behavior with transition tables in update statement trigger (Thomas Munro <thomas.munro@enterprisedb.com>) |
Список | pgsql-hackers |
On Tue, Feb 27, 2018 at 02:52:02PM +1300, Thomas Munro wrote: >On Tue, Feb 27, 2018 at 4:18 AM, Tom Kazimiers <tom@voodoo-arts.net> wrote: >> It would be great if this or a similar fix would make it into the >> next official release. > >Here's a new version with tuplestore_select_read_pointer() added in >another place where it was lacking, and commit message. Moving to >-hackers, where patches go. Thanks and just to confirm the obvious: the new patch still fixes this bug in both my test trigger function and my real trigger function. >Here's a shorter repro. On master it prints: > >NOTICE: count = 1 >NOTICE: count union = 1 > >With the patch the second number is 2, as it should be. > >CREATE TABLE test (i int); >INSERT INTO test VALUES (1); > >CREATE OR REPLACE FUNCTION my_trigger_fun() RETURNS trigger >LANGUAGE plpgsql AS >$$ > BEGIN > RAISE NOTICE 'count = %', (SELECT COUNT(*) FROM new_test); > RAISE NOTICE 'count union = %', (SELECT COUNT(*) > FROM (SELECT * FROM new_test UNION ALL SELECT * FROM new_test) ss); > RETURN NULL; > END; >$$; > >CREATE TRIGGER my_trigger AFTER UPDATE ON test >REFERENCING NEW TABLE AS new_test OLD TABLE as old_test >FOR EACH STATEMENT EXECUTE PROCEDURE my_trigger_fun(); > >UPDATE test SET i = i; That's a much cleaner repro (and test case I suppose), thanks. Tom
В списке pgsql-hackers по дате отправления: