On Sun, Oct 23, 2011 at 21:39, Tom Lane t...@sss.pgh.pa.us wrote:
I will try to come up with a new patch in a few days (haven't had too
much time lately).
Oh, I did it already.
Cool.
I noticed now that you didn't add a regression test for this fix.
Perhaps you could reuse the test from my
On Sun, Oct 23, 2011 at 06:44, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think maybe what we should do is add
an immediate field to IndexOptInfo, mirroring the existing unique
flag, and have get_relation_info() populate it from indimmediate, and
then make
Marti Raudsepp ma...@juffo.org writes:
On Sun, Oct 23, 2011 at 06:44, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, this seems like the right fix.
Oh, that sounds pretty obvious now that you mention it. :)
I will try to come up with a new patch in a few days (haven't had too
much time lately).
Robert Haas robertmh...@gmail.com writes:
Yuck. Well, that's certainly a bug. What's weird is that I thought
we had put logic into the join removal code to ignore deferrable
constraints. Apparently not.
I poked around a bit more and could not find any evidence that we'd
ever done that. Ah
On Wed, Oct 19, 2011 at 7:35 AM, Marti Raudsepp ma...@juffo.org wrote:
This probably doesn't affect many real-world applications, but it
seems wrong that a performance feature can affect results returned by
a query.
Test case:
create table uniq (i int unique deferrable initially deferred);
Robert Haas robertmh...@gmail.com writes:
Yuck. Well, that's certainly a bug. What's weird is that I thought
we had put logic into the join removal code to ignore deferrable
constraints.
Yeah, I thought we had too.
regards, tom lane
--
Sent via pgsql-hackers
