On Tue, 2007-05-29 at 22:41 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > On Tue, 2007-05-29 at 18:10 +0100, Gregory Stark wrote:
> >> It has the same problem that SELECT triggers have. How many rows should you
> >> expect that subquery to insert, update, or delete if it's used in a join
> >> clause? Or in the where clause of another insert/update/delete statement?
>
> > We could handle it essentially like a volatile set-returning function.
>
> Uh-huh. Please provide a concise, accurate definition of what that
> does. For extra points, be sure it describes the behavior of all recent
> Postgres versions. (And after that, we could argue about whether we
> actually *like* the described behavior ... which I'll bet we won't.)
>
I understand that we don't make many guarantees about when and how many
times volatile functions are executed (the most obvious example is the
WHERE clause).
I also understand the argument that we don't want to extend that
uncertainty to UPDATE ... RETURNING.
It is possible to define behavior though, because it's already done for
volatile functions. Even if it's not a good definition, and even if that
definition changes between versions and is non-deterministic, it seems
like it offers some kind of starting place.
Regards,
Jeff Davis
