Re: Not understanding this behavior of a subselect + volatile function

Поиск
Список
Период
Сортировка
От Chris Angelico
Тема Re: Not understanding this behavior of a subselect + volatile function
Дата
Msg-id CAPTjJmoxonUG1W5zpQqcwR+9+7g1shXKiqWK5aFFj3u+BLPRqg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Not understanding this behavior of a subselect + volatile function  (Brian Palmer <brian@codekitchen.net>)
Ответы Re: Not understanding this behavior of a subselect + volatile function  (Brian Palmer <brian@codekitchen.net>)
Список pgsql-general
On Sun, May 27, 2012 at 11:36 AM, Brian Palmer <brian@codekitchen.net> wrote:
> That's a good link, thanks Chris. I'm not sure it entirely answers what I'm
> seeing though. It does explain why the outer select doesn't see the updated
> values, but the other thing that I'm seeing is that sometimes the function
> will update a row that was just inserted, and then the outer select will
> return 0 results. It behaves as if from the view of the outer select, that
> row doesn't exist yet. So I end up with a row in the table that's been
> updated by the function, but never returned to the caller.

I seem to recall reading somewhere that the WHERE is processed like an
"intervening if" clause in Magic: The Gathering - it's checked both
before and after the function is called. Perhaps this is solvable, but
if not, I'd be inclined to treat it like C and avoid referencing and
altering a variable in one expression (eg arr[i++]=i; is a bad idea).

There are experts on this list, though, and I am not one :)

ChrisA

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

Предыдущее
От: Brian Palmer
Дата:
Сообщение: Re: Not understanding this behavior of a subselect + volatile function
Следующее
От: Brian Palmer
Дата:
Сообщение: Re: Not understanding this behavior of a subselect + volatile function