Re: PL/pgSQL bug?

> 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