On Mon, Nov 8, 2010 at 12:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> writes:
>> On 2010-11-08 6:38 PM +0200, Tom Lane wrote:
>>> My opinion is still the same as here:
>>> http://archives.postgresql.org/pgsql-hackers/2010-02/msg00688.php
>>>
>>> namely, that all we should be worrying about is a tuplestore full of
>>> RETURNING tuples. Any other side-effects of a DML subquery should
>>> *not* be visible to the calling query, and therefore all this argument
>>> about snapshots and seqscan limits is beside the point.
>
>> What happened to:
>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php ?
>
> On the whole, I think that's overspecifying the behavior. Compare what
> happens if you do the same thing in one query now; that is, you have
> say an UPDATE query and within that you invoke some function that looks
> directly at the target table. Is it going to see a consistent view of
> the data? No, it's going to see a partially updated table.
>
> The argument I'm making at the moment is
> [exactly the opposite of what I said before]
You've now vetoed both "using the same snapshot" and "using different
snapshots" at different points in time. Had you taken your current
position at this time a year ago, we might well have this feature in
9.0. I guess that's water under the bridge at this point, but I
believe that a pretty substantial amount of work has gone into
whacking this patch around based on your previously-expressed views as
to how it should be implemented, and they seem to have just shifted
again.
Frankly, I buy both arguments. I think that if we use the same
snapshot, we are going to get people complaining about really screwy
behavior if the same table is used more than once in the same query
(BEFORE triggers already make my head explode). I think if we use
different snapshots, optimization is going to be rather difficult, and
people are going to complain about the performance. So I don't know
what the right thing to do is, but it is not the case that we are
designing this tabula rasa.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company