On Wed, 13 Nov 2024, 11:11 Peter Eisentraut, <peter@eisentraut.org> wrote:
> This conditional is really hard to understand:
>
> + /*
> + * The AM must support uniqueness, and the index must in fact be
> unique.
> + * If we have a WITHOUT OVERLAPS constraint (identified by
> uniqueness +
> + * exclusion), we can use that too.
> + */
> + if ((!indexRel->rd_indam->amcanunique ||
> + !indexRel->rd_index->indisunique) &&
> + !(indexRel->rd_index->indisunique &&
> indexRel->rd_index->indisexclusion))
>
> Why can we have a indisunique index when the AM is not amcanunique? Are
> we using the fields wrong?
I called this issue out earlier this year: amcanunique implies
btree-style uniqueness, and allows CREATE UNIQUE INDEX. However, that
IndexAmRoutine field seems to be ignored for indexes that are created
to back temporal unique constraints, which thus get
indrel->indisunique = true. This causes interesting issues when you
look at the index catalog and errors: there are indexes with
indisunique using gist, but CREATE UNIQUE INDEX USING gist (...)
throws the nice "access method "gist" does not support unique indexes"
error.
It'd be nice if there was a better internal API to describe what types
of uniqueness each index supports, so CREATE UNIQUE INDEX could work
with gist for WITHOUT OVERLAPS, and these WITHOUT OVERLAPS unique
indexes could be attached to primary keys without taking O(>=
tablesize) of effort.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
