Re: plpgsql gram.y make rule - Mailing list pgsql-hackers

From Tom Lane
Subject Re: plpgsql gram.y make rule
Date
Msg-id 1732.1348539702@sss.pgh.pa.us
Whole thread Raw
In response to plpgsql gram.y make rule  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: plpgsql gram.y make rule  (Dan Scott <denials@gmail.com>)
List pgsql-hackers
Peter Eisentraut <peter_e@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch: incorrect array offset in backend replication tar header
Next
From: Brian Weaver
Date:
Subject: Re: Patch: incorrect array offset in backend replication tar header