Re: Unexpected behavior with transition tables in update statement trigger

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(at)voodoo-arts(dot)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