Tom Lane <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> I was also considering going ahead and implementing Hannu's ALTER INDEX SET >> UNIQUE too. > > Don't waste your time, when we don't have an algorithm that would make > it work. It's too late for 8.2 anyway...
Oh, I think ALTER INDEX SET UNIQUE is easy, at least algorithm-wise. We set the index to be unique, then wait until everyone can see it. Then we scan to make sure there's only one live tuple for each key value. As long as it's unique in our snapshot and we can be sure that any concurrent changes will preserve that property then we can be sure it's good. Hm, I suppose we have to keep the index marked invalid during this operation so it doesn't appear as if there's a promise that the data is unique. That's fine for freshly built concurrent indexes but not so nice for an existing non-unique index. We might need a new column induniqueisvalid that indicates that a unique constraint can't be trusted yet. I suppose it's 8.3 material. And maybe not even the most urgent item either. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
