On Fri, Oct 7, 2011 at 07:53, Robert Haas <robertmhaas@gmail.com> wrote:
> The only way we could
> trip up in that case is if there were two identically named
> constraints. We'd have to visit the first tuple, update it, then
> visit the second tuple, recurse (thus incrementing the command
> counter), and then visit the updated version of the first tuple. And
> that should be impossible, because we've got code to disallow multiple
> constraints on the same relation with the same name (though no unique
> index, for some reason).
Surely an oversight...
> Still, that's a long chain of reasoning, so
> I'm wondering if we can't come up with something that is more
> obviously correct.
>
> If we're confident that the inner loop here should never iterate more
> than once (i.e. the lack of a unique index is not an ominous sign)
> then maybe we should just rewrite this so that the inner loop scans
> until it finds a match and then terminates. Then, outside the loop,
> we check whether a tuple was found and if so process it - but without
> ever going back to look for another one. See attached.
I eyeballed it and it does indeed seem simpler. My only thought is
perhaps we should add that missing unique index on (conrelid,
conname). If we are not going to support duplicate names in the code,
we might as well enforce it. No?
