Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table |
Дата | |
Msg-id | 476.1496672108@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table
Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Sat, Jun 3, 2017 at 10:39 PM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> In the meantime, it seems like you agree that rejecting wCTEs that >> affect tables with triggers with transition tables is the best >> response to this bug report? Do you think that parse analysis is the >> right time to do the check? Here's a first attempt at that. FWIW, parse analysis is surely NOT the time for such a check. Triggers might get added to a table between analysis and execution. I think you might have to do it during executor startup. > I'm starting to like the approach of reverting the entire transition > tables patch. Failing to consider the possibility of a plan with > multiple ModifyTable nodes seems like a pretty fundamental design > mistake, and I'm not eager either to ship this with that broken or try > to fix it at this stage of the release cycle. Postponing the feature to v11 might be a viable solution. We don't have any other major work that depends on it do we? regards, tom lane
В списке pgsql-hackers по дате отправления: