Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Of course the downside of changing it is that queries that worked fine
before might work differently (and much slower) now; first because not
flattening the sub-select might lead to a
On Mon, Oct 12, 2009 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Of course the downside of changing it is that queries that worked fine
before might work differently (and much
I'm fooling around with pushing FOR UPDATE locking into a new plan node
type, and I just noticed a behavior that seems a bit bogus.
Historically we have dealt with FOR UPDATE in sub-selects by flattening
the sub-select if we could, because the alternative was to fail
altogether. For example,
Hi,
Tom Lane wrote:
It's an entirely trivial code change either way. I'm inclined to think
that we should prevent flattening, on the grounds of least astonishment.
Yeah, I also tend towards making FOR UPDATE an optimization fence
(that's how I understood the non-flattening approach). While it
Markus Wanner mar...@bluegap.ch writes:
BTW: how do other databases deal with this? Anything of relevance in the
SQL standards?
SQL99 treats FOR UPDATE as an attribute of DECLARE CURSOR, so there's
no way for it to appear in a sub-select per spec. (In general our
approach to FOR UPDATE is only
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm fooling around with pushing FOR UPDATE locking into a new plan node
type, and I just noticed a behavior that seems a bit bogus.
Historically we have dealt with FOR UPDATE in sub-selects by flattening
the sub-select if we
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's an entirely trivial code change either way. I'm inclined to think
that we should prevent flattening, on the grounds of least astonishment.
It seems like this is somewhat
