Re: Unexpected behavior with transition tables in update statement trigger - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Unexpected behavior with transition tables in update statement trigger
Date
Msg-id CAEepm=3mBBHij-YQwgUmj2zvNs4q8KjYb5j10dnKpuCfXhk1PQ@mail.gmail.com
Whole thread Raw
In response to Re: Unexpected behavior with transition tables in update statement trigger  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unexpected behavior with transition tables in update statementtrigger
Re: Unexpected behavior with transition tables in update statementtrigger
List pgsql-hackers
On Wed, Feb 28, 2018 at 9:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> 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.
>
> Pushed, along with a regression test based on your example.
> Unfortunately, this came in a bit too late for this week's releases :-(

Thanks!

Tom K, if you need a workaround before 10.4 comes out in May[1], you
could try selecting the whole transition table into a CTE up front.
Something like WITH my_copy AS (SELECT * FROM new_table) SELECT * FROM
my_copy UNION ALL SELECT * FROM my_copy should work.

[1] https://www.postgresql.org/developer/roadmap/

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: PATCH: Exclude unlogged tables from base backups
Next
From: Tom Kazimiers
Date:
Subject: Re: Unexpected behavior with transition tables in update statementtrigger