On Fri, Oct 7, 2011 at 11:19 AM, Alex Hunsaker <bada...@gmail.com> wrote: > On Fri, Oct 7, 2011 at 07:53, Robert Haas <robertmh...@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?
Not sure. There could be performance or other ramifications to that. For now I'm more interested in fixing this particular bug than I am in getting into a wider world of re-engineering... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers