Re: Unexpected behavior with transition tables in update statement trigger
От | Thomas Munro |
---|---|
Тема | Re: Unexpected behavior with transition tables in update statement trigger |
Дата | |
Msg-id | CAEepm=3mBBHij-YQwgUmj2zvNs4q8KjYb5j10dnKpuCfXhk1PQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Unexpected behavior with transition tables in update statement trigger (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Unexpected behavior with transition tables in update statementtrigger
Re: Unexpected behavior with transition tables in update statementtrigger |
Список | 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 по дате отправления: