On 4 June 2017 at 06:41, Kevin Grittner <kgri...@gmail.com> wrote: > On Fri, Jun 2, 2017 at 8:46 PM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: > >> So, afterTriggers.query_stack is used to handle the reentrancy that >> results from triggers running further statements that might fire >> triggers. It isn't used for dealing with extra ModifyTable nodes that >> can appear in a plan because of wCTEs. Could it also be used for that >> purpose? I think that would only work if it is the case that each >> ModifyTable node begin and then runs to completion (ie no interleaving >> of wCTE execution) and then its AS trigger fires, which I'm not sure >> about. > > I don't think we want to commit to anything that depends on a CTE > creating an optimization fence, although *maybe* that would be OK in > the case of DML as a CTE. That's a pretty special case; I'm not > sure whether the standard discusses it.
It's definitely fine to require a fence for wCTEs. They're an extension to the standard, and it's pretty much necessary that we not pull up / push down across them since we don't want to affect the side-effects (row changes). If there are any cases where it's safe, they'll take some careful thought. It's only standard CTEs (SELECT-based) that I think matter for the optimisation fence behaviour. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
