Re: PL/pgSQL bug?

I am not sure if there is a TODO item here, but if there is, please let
me know.  Thanks.


> > -----Original Message-----
> > From: Tom Lane
> > 
> > I believe the reason for this is that in Read Committed mode,
> > each separate query from the client computes a new snapshot (see
> > SetQuerySnapshot calls in postgres.c).  So, when your
> > "select ctid, i from t1" query executes, it computes a snapshot
> > that says T1 is committed, and then it doesn't see the row left
> > over from T1.  On the other hand, your plpgsql function operates
> > inside a single client query and so it's using just one QuerySnaphot.
> > 
> > One way to make the results equivalent is to compute a new QuerySnapshot
> > for each SPI query.  Quite aside from the cost of doing so, I do not
> > think it makes sense, considering that the previous QuerySnapshot must
> > be restored when we return from the function.  Do we really want
> > functions to see transaction status different from what's seen outside
> > the function call?
> 
> Yes I do.
> 
> >  I doubt it.
> > 
> > The other way to make the results the same is to omit the
> > SetQuerySnapshot calls for successive client-issued queries in one
> > transaction.
> 
> What's different from SERIALIZABLE mode ?
> 
> regards,
> Hiroshi Inoue
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026