Greg Stark <gsst...@mit.edu> writes:
> On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> However, the real reason for doing it isn't any of those, but rather
>> to establish the principle that the executions of the modifying
>> sub-queries are interleaved not sequential.
> Does the interleaved execution have sane semantics?
Depends on what you call sane. With the decision to not increment
command counter, it's already the case that people shouldn't have
two subqueries try to modify the same row.
> With a query like:
> WITH
> a as update x set x.i=x.i+1 returning x.i,
> b as update x set x.i=x.i+1 returning x.i
> select * from a natural join b;
> Is there any way to tell what it will return or what state it will
> leave the table in?
My reaction to that is "you shouldn't do that, and you definitely
shouldn't complain if it's not predictable whether a or b will
modify a given row". This is exactly the sort of assumption I don't
want people building into their queries, because we will be locked
into purely sequential execution if we promise that the results will
be consistent.
There is already precedent for that position. You can easily construct
queries using UPDATE ... FROM wherein the same target row joins to more
than one row in the FROM table, and then it's unpredictable which
joining row will be used to update that target row. Our position has
always been "don't do that", not that we'd lobotomize the planner and
executor to ensure predictability.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
