Re: Bug? Function with side effects not evaluated in CTE
От | Merlin Moncure |
---|---|
Тема | Re: Bug? Function with side effects not evaluated in CTE |
Дата | |
Msg-id | CAHyXU0x9cinvW8Vkc_tGvCK-DNUFkg+R3Z9ABWCF5sVM6je-Jg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug? Function with side effects not evaluated in CTE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug? Function with side effects not evaluated in CTE
|
Список | pgsql-general |
On Wed, Oct 16, 2013 at 4:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Moshe Jacobson <moshe@neadwerx.com> writes: >> However, It behaves as one would expect if the first CTE is built with INSERT >> ... RETURNING. > > CTEs containing INSERT/UPDATE/DELETE are guaranteed to be executed exactly > once. CTEs containing SELECTs are guaranteed to be executed at most once > (the documentation phrases that as "execution can stop early if the outer > query doesn't read all the rows" --- in this case, it read none of them, > since the outer query never had to evaluate the NOT IN). > > I see no bug here. You can force the CTE to be read a couple of different ways; it isn't very difficult to do: just tweak the final query so that it *must* touch the SELECT result somehow (e.g. AND (SELECT COUNT(*) FROM tt_created) > 0). That being said, I do think it might be better behavior (and still technically correct per the documentation) if volatile query expressions were force-evaluated. merlin
В списке pgsql-general по дате отправления: