Re: SetQuerySnapshot, once again

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: SetQuerySnapshot, once again
Дата
Msg-id 3D113213.382F728C@tpf.co.jp
обсуждение исходный текст
Ответ на Re: SetQuerySnapshot, once again  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
Tom Lane wrote:
> 
> 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.

Oops I was wrong. The last *stable* isn't needed.
> This idea might be a bit off-the-wall,

Probably I mentioned once long before.
We can't expect reasonable result for  select fn1(..), fn2(..), ... from ... ;
if there are some fnx()-s with strong side effect.

> 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.

IMHO it's impossible to handle anything with one concept.
Functions could be *immutable*(? deterministic in SQL99)
or *stable* even though they have strong side effect.

regards,
Hiroshi Inouehttp://w2422.nsk.ne.jp/~inoue/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: ecpg and bison again
Следующее
От: Ryan Mahoney
Дата:
Сообщение: Re: count and group by question