Kenneth Marshall <ktm@rice.edu> writes:
> On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote:
>>> Attached patch cleanups hash index headers to allow compile hasham for
>>> 8.3 version. It helps to improve pg_migrator with capability to migrate
>>> database with hash index without reindexing.
> How does that work with the updated hash functions without a reindex?
I looked at this patch and I don't see how it helps pg_migrator at all.
It's just pushing some code and function declarations around.
The rearrangement might be marginally nicer from a code beautification
point of view --- right now we're a bit inconsistent about whether
datatype-specific hash functions live in hashfunc.c or in the datatype's
utils/adt/ file. But I'm not sure that removing hashfunc.c altogether is
an appropriate solution to that, not least because of the loss of CVS
history for the functions. I'd be inclined to leave the core hash_any()
code where it is, if not all of these functions altogether.
What does seem useful is to refactor the headers so that datatype hash
functions don't need to include all of the AM's implementation details.
But this patch seems to do both more and less than that --- I don't
think it's gotten rid of all external #includes of access/hash.h, and
in any case moving the function code is not necessary to that goal.
In any case, the barriers to implementing 8.3-style hash indexes in 8.4
are pretty huge: you'd need to duplicate not only the hash AM code, but
also all the hash functions, and therefore all of the hash pg_amop and
pg_amproc entries. Given the close-to-zero usefulness of hash indexes
in production installations, I don't think it's worth the trouble. It
would be much more helpful to look into supporting 8.3-compatible GIN
indexes.
regards, tom lane