Re: Unexpected behavior with transition tables in update statement trigger

From: Tom Kazimiers <tom(at)voodoo-arts(dot)net>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Unexpected behavior with transition tables in update statement trigger
Date: 2018-02-27 22:54:44
Message-ID: 20180227225444.haimi5j2equ5fzeg@dewberry.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Feb 28, 2018 at 10:27:23AM +1300, Thomas Munro wrote:
>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/

Thanks, that's what I am going to do.

Cheers,
Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-02-27 23:12:45 Re: Reopen logfile on SIGHUP
Previous Message Tom Lane 2018-02-27 22:52:20 Re: Reopen logfile on SIGHUP

Browse pgsql-general by date

  From Date Subject
Next Message Thiemo Kellner 2018-02-27 22:58:23 Re: Creating complex track changes database - challenge!
Previous Message Andres Freund 2018-02-27 22:11:41 Re: index-only-scan when there is an index on all columns