Re: Not understanding this behavior of a subselect + volatile function - Mailing list pgsql-general

From Chris Angelico
Subject Re: Not understanding this behavior of a subselect + volatile function
Date
Msg-id CAPTjJmoxonUG1W5zpQqcwR+9+7g1shXKiqWK5aFFj3u+BLPRqg@mail.gmail.com
Whole thread Raw
In response to Re: Not understanding this behavior of a subselect + volatile function  (Brian Palmer <brian@codekitchen.net>)
Responses Re: Not understanding this behavior of a subselect + volatile function
List 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 by date:

Previous
From: Brian Palmer
Date:
Subject: Re: Not understanding this behavior of a subselect + volatile function
Next
From: Brian Palmer
Date:
Subject: Re: Not understanding this behavior of a subselect + volatile function