Peter Eisentraut <pete...@gmx.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
