Joel Jacobson writes:
> If helpful, here is a simple test to reproduce the problem:
> http://pgsql.privatepaste.com/6429e8a200
FWIW, this is fixed already in git, or at least this particular example
gives what seems the right answer:
fooid | barid | fooint
---+---+
2 |
When I tried our test suite against 9.2.1 one of the tests failed,
it looked really strange, the query had returned a row which could
impossibly match the WHERE statement.
I heard on #postgresql this bug has already been reported.
If helpful, here is a simple test to reproduce the problem:
http:/
On 16 October 2012 16:56, Tom Lane wrote:
> Is anybody concerned about the compatibility implications of fixing this
> bug in the back branches? I'm worried about people complaining that we
> broke their application in a minor release. Maybe they were depending
> on incorrect behavior, but they
I wrote:
> So this is essentially an oversight in the patch that added tracking of
> nullable_relids. I got confused about the difference between
> outerjoin_delayed (this clause, as a whole, is not outerjoin_delayed
> because its natural semantic level would be at the join anyway) and
> having no
On Tue, Oct 16, 2012 at 11:56:52AM -0400, Tom Lane wrote:
> Is anybody concerned about the compatibility implications of fixing this
> bug in the back branches? I'm worried about people complaining that we
> broke their application in a minor release. Maybe they were depending
> on incorrect beha
I looked into the problem reported in bug #7604 (Bill MacArthur was kind
enough to send me a reproducer off-list). The error can be demonstrated
by this example in the regression test database:
select f1, unique2, case when unique2 is null then f1 else 0 end
from int4_tbl a left join tenk1 b on
