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 по дате отправления:

Предыдущее
От: "Tony Griffiths(RA)"
Дата:
Сообщение: Re: Missing library files??
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: SQL99 feature list