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. 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. -- Simon Riggs http://www.EnterpriseDB.com/
strategyam.v1.patch
Description: Binary data
