Re: alter table only ... drop constraint broken in HEAD

On Fri, Oct 7, 2011 at 11:19 AM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> On Fri, Oct 7, 2011 at 07:53, Robert Haas <robertmhaas(at)gmail(dot)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