David Johnston <polobo@yahoo.com> writes:
> As to Tom's "defined the same way" - does it truly mean "has index" or is it
> "has unique index defined as primary"? I ask because depending on how the
> data is being used it may be worth it to a caller to force the flag to be
> the correct value to avoid subsequent checks.
AFAIR, the backend does not use relhaspkey at all. (If it weren't for
client-compatibility worries, we'd probably have removed the field
altogether long ago.)
We do use relhasindex to know whether it's worth looking in pg_index or
not when collecting data about a table. Thus the definition that
relhasindex *must* be true if there are indexes. If it's true when there
are not indexes, though, we just waste one indexed search of pg_index
which is not a big deal.
I believe the killer reason why relhasindex is inaccurate in this way is
that if we didn't define it like that, concurrent CREATE INDEXes on the
same table couldn't work. The update that sets relhasindex true is
nontransactional, meaning it won't roll back if an index creation fails;
but that's needed to avoid having concurrent CREATE INDEXes block each
other while trying to update the pg_class row.
regards, tom lane
