Re: [BUGS] BUG #14808: V10-beta4, backend abort
От | Thomas Munro |
---|---|
Тема | Re: [BUGS] BUG #14808: V10-beta4, backend abort |
Дата | |
Msg-id | CAEepm=015ZFuo2AEFF+maS2AvL7PGkdZ_=uUErpPXzNm3TbGWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14808: V10-beta4, backend abort (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] BUG #14808: V10-beta4, backend abort
|
Список | pgsql-bugs |
On Tue, Sep 12, 2017 at 12:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > OTOH, looking at the text of > the spec, I think it's darn hard to justify the behavior shown above. Yeah. I assume we always fired statement triggers for each separate instance of the same table mentioned in a wCTE since they were invented. I just confirmed that that is the case in 9.6. That may not have been in the spirit of the spec, but it's hard to say because the spec doesn't have wCTEs IIUC and it mattered less because they didn't receive any data. Now that they can optionally see data resulting from modifications, it seems pretty hard to use this feature to build anything that consumes the transition data and has to be reliable (matview state, replication-like systems etc) if we make any choice other than (1) each instance of a given table fires a statement trigger separately and sees only the rows it touched, or (2) the statement trigger is fired once for all instances of a table, and sees all the transition tuples. Based on the SQL spec excerpts you've highlighted, I suppose it seems likely that if the spec had wCTEs it would expect them to work like (2). -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: