Robert Haas <robertmhaas@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 well.
> 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 relation_has_unique_index() disqualify any non-immediate
> index.
Yeah, this seems like the right fix. I considered redefining the unique
flag to mean indisunique && indimmediate, but that's wrong because of:
> has_unique_index() arguably needs a similar fix, although at present
> that appears to be used for only statistic purposes, so maybe it's OK.
Yes, since this is meant for statistical purposes, I think it's
appropriate for it to disregard indimmediate.
> A comment update might be a good idea, though.
Or we could add a parameter to have the caller indicate which behavior
is wanted. But for now I think a comment is enough.
regards, tom lane
