On Tue, 2006-12-12 at 19:13 -0500, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> 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
