Hi, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
