On Tue, 2006-12-12 at 19:13 -0500, Tom Lane wrote: > Jeff Davis <pgsql@xxxxxxxxxxx> writes: > > On Tue, 2006-12-12 at 18:40 -0500, Tom Lane wrote: > >> No. What happens if someone renames the table out from under you, to > >> mention just one possibility? > > > I'm trying to understand what would actually happen. I assume you mean > > change the name of the index, because after we create the index > > concurrently, it doesn't matter what the table name is. > > Well, if you don't like that one, consider ALTER OWNER revoking your > privilege to perform the REINDEX. Without an explicit check for the > case, the code would proceed to do it anyway. (And even if it did > check, what then? You don't really have the right anymore to undo what > you did so far, either.) > > Yeah, we could add defenses one by one for the cases we could think of, > but I'd never feel very secure that we'd covered them all. > Ok, fair enough. I just wanted to make sure I understood the reason why we couldn't (shouldn't?) do it. > Another point here is that I think you are assuming that an OID is a > unique-for-all-time identifier for a table or index. It's not; as soon > as someone drops the table or index, the OID is up for grabs and could > be re-used for an unrelated table or index. Admittedly one would have > to be quite unlucky to get burnt that way, but deliberately introducing > race conditions in the name of convenience is not my idea of the way to > design a database. > It essentially does boil down to just convenience. In general we don't have much ability to change primary key status for columns without creating/dropping indexes non-concurrently. Admittedly, that isn't important, but would be convenient. Regards, Jeff Davis
