Re: plpgsql gram.y make rule

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I wanted to refactor the highly redundant flex and bison rules
> throughout the source into common pattern rules. (Besides saving some
> redundant code, this could also help some occasionally flaky code in
> pgxs modules.) The only outlier that breaks this is in plpgsql

> pl_gram.c: gram.y

> I would like to either rename the intermediate file(s) to gram.{c,h}, or
> possibly rename the source file to pl_gram.y. Any preferences or other
> comments?

Hmmm ... it's annoyed me for a long time that that file is named the
same as the core backend's gram.y. So renaming to pl_gram.y might be
better. On the other hand I have very little confidence in git's
ability to preserve change history if we do that. Has anyone actually
done a file rename in a project with lots of history, and how well did
it turn out? (For instance, does git blame still provide any useful
tracking of pre-rename changes? If you try to cherry-pick a patch
against the new file into a pre-rename branch, does it work?)

regards, tom lane