On Tue, 19 Jul 2022 at 18:56, Simon Riggs <simon.riggs@enterprisedb.com> wrote:
>
> I'm preparing the way for a later patch that would allow unique hash
> indexes to be primary keys. There are various parts to the problem. I
> was surprised at how many times we hardcode BTREE_AM_OID and
> associated BT Strategy Numbers in many parts of the code, so have been
> looking for ways to reconcile how Hash and Btree strategies work and
> potentially remove hardcoding. There are various comments that say we
> need a way to be able to define which Strategy Numbers are used by
> indexams.
>
> I came up with a rather simple way: the indexam just says "I'm like a
> btree", which allows you to avoid adding hundreds of operator classes
> for the new index, since that is cumbersome and insecure.
I'm fairly certain that you can't (and don't want to) make a hash
index look like a btree index, considering that of the btree
operations only equality checks make sense in the hash context, and
that you can't do ordered retrieval (incl. no min/max), which are
major features of btree.
With that in mind, could you tell whether this patch is related to the
effort of hash-based unique primary keys (apart from inspiration
during development), and if so, how?
> Specifically, we add a "strategyam" field to the IndexAmRoutine that
> allows an indexam to declare whether it is like a btree, like a hash
> index or another am. This then allows us to KEEP the hardcoded
> BTREE_AM_OID tests, but point them at the strategyam rather than the
> relam, which can be cached in various places as needed. No catalog
> changes needed.
>
> I've coded this up and it works fine.
>
> The attached patch is still incomplete because we use this in a few
> places and they all need to be checked. So before I do that, it seems
> sensible to agree the approach.
>
> (Obviously, there are hundreds of places where BTEqualStrategyNumber
> is hardcoded, and this doesn't change that at all, in case that wasn't
> clear).
>
> Comments welcome on this still WIP patch.
I think this is a great step in the right direction, fixing one of the
issues with core index AMs, issues I also complained about earlier
[0].
Thanks,
Matthias van de Meent
[0] https://www.postgresql.org/message-id/CAEze2Wg8QhpOnHoqPNB-AaexGX4Zaij%3D4TT0kaMhF_6T5FXxmQ%40mail.gmail.com
