Re: SetQuerySnapshot, once again
От | Tom Lane |
---|---|
Тема | Re: SetQuerySnapshot, once again |
Дата | |
Msg-id | 4240.1024496700@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SetQuerySnapshot, once again (Hiroshi Inoue <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
Hiroshi Inoue <Inoue@tpf.co.jp> writes: >> I do not like the idea of treating the first select in a function >> differently from the rest. And such a rule wouldn't let you build >> guaranteed-stable functions anyway; > AFAIK there has been no analysis where we can get *stable* > functions. As far as I see, we can expect SELECT-only functions > to be *stable* if and only if they are surrounded by SELECT-only > *stable* functions. This idea might be a bit off-the-wall, but how about: 1. If a plpgsql function is declared immutable or stable, then all its queries run with the same snapshot *and* CommandCounterId as prevail in the calling query. Probably we should disallow it from making any updating queries, too; allow only SELECTs. 2. If it's declared volatile (the default), then snapshot and CommandCounterId are both updated for each query in the function, including the first one. So the default behavior would be equivalent to issuing the same queries interactively, which I think is a good default. The non-default behavior would allow truly stable functions to be built. regards, tom lane
В списке pgsql-hackers по дате отправления: