Re: WIP: push AFTER-trigger execution into ModifyTable node
| От | Marko Tiikkaja |
|---|---|
| Тема | Re: WIP: push AFTER-trigger execution into ModifyTable node |
| Дата | |
| Msg-id | 4AEDA79B.8050508@cs.helsinki.fi обсуждение исходный текст |
| Ответ на | Re: WIP: push AFTER-trigger execution into ModifyTable node (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: WIP: push AFTER-trigger execution into ModifyTable node
|
| Список | pgsql-hackers |
Tom Lane wrote: > However, this still doesn't address the problem of what happens when the > top-level select fails to read all of the CTE output (because it has a > LIMIT, or the client doesn't read all the output of a portal, etc etc). > Partially executing an update in such cases is no good. I've previously thought about making the CTE aware of the LIMIT, similarly to a top-N sort, but I don't think it's worth it. If we have a LIMIT, we could just fall back to the statement-at-the-time execution. I'm not sure what all cases you mean with "the client doesn't read all the output of a portal", but at least for cursors we'd have to first execute ModifyTable nodes. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: