> No we don't. There are no SetQuerySnapshot calls occuring *within*
> a query. An example of why that would be unacceptable: consider
>
> select myfunc(f1) from table where f2 = 42;
>
> Suppose executing myfunc() causes an unrestored SetQuerySnapshot call.
> Then, if other transactions are busy changing f2 values, the set of
> rows that this query returns could depend on the order in which rows
> are visited --- since whether it thinks a row with f2 = 42 is visible
> might depend on whether any previous rows had been matched (causing
> myfunc() to be evaluated). For that matter, it could depend on the
> form of the query plan used --- in some plans, myfunc() might be called
> while the scan is in progress, in others not till afterward.
If so, FROM clause-less SELECT (select myfunc();) might be ok.
> > For example, COPY TO calls SetQuerySnapshot
> > (see tcop/utility.c).
>
> That's just because postgres.c doesn't do it automatically for utility
> statements. There's still just one SetQuerySnapshot per query.
I'm confused. In my example:
CREATE FUNCTION myftest(INT)
RETURNS INT
AS ' UPDATE t1 SET i = 1 WHERE i = 1; COPY t1 TO ''/tmp/t1.data''; SELECT i FROM t1 WHERE i = (SELECT i FROM t1 WHERE i
=1);'LANGUAGE 'sql';
When COPY is invoked in the function, I thought SetQuerySnapshot is
called.
So "SELECT myftest(1);" would call SetQuerySnapshot twice, no?
--
Tatsuo Ishii