Re: [HACKERS] CTE inlining
От | Joe Conway |
---|---|
Тема | Re: [HACKERS] CTE inlining |
Дата | |
Msg-id | 4f98ca61-798b-8751-b2a7-7b0af2bc237b@joeconway.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] CTE inlining (Craig Ringer <craig.ringer@2ndquadrant.com>) |
Список | pgsql-hackers |
On 05/04/2017 05:03 PM, Craig Ringer wrote: > On 5 May 2017 02:52, "Tom Lane" wrote: > I haven't been keeping close tabs either, but surely we still have > to have > the optimization fence in (at least) all these cases: > > * CTE contains INSERT/UPDATE/DELETE > * CTE contains SELECT FOR UPDATE/SHARE (else the set of rows that get > locked might change) > * CTE contains volatile functions > > I'm willing to write off cases where, eg, a function should have been > marked volatile and was not. That's user error and there are plenty > of hazards of that kind already. But if the optimizer has reason > to know that discarding the fence might change any query side-effects, > it mustn't. > > I think everyone is in total agreement there. That's great, but if so, why do we need any change in syntax at all? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
В списке pgsql-hackers по дате отправления: