Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)

Hi,

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

I guess someone has to talk about it: git will follow the code even when
the file hosting it changes. It's not all magic though:

http://kerneltrap.org/node/11765

"And when using git, the whole 'keep code movement separate from
changes' has an even more fundamental reason: git can track code
movement (again, whether moving a whole file or just a function
between files), and doing a 'git blame -C' will actually follow code
movement between files. It does that by similarity analysis, but it
does mean that if you both move the code *and* change it at the same
time, git cannot see that 'oh, that function came originally from that
other file', and now you get worse annotations about where code
actually originated."

Having better tools maybe could help maintain the high quality standards
that are established code wise, too.

Regards,
--
dim