Re: [HACKERS] plpgsql gram.y make rule
On Mon, Sep 24, 2012 at 10:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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?)
git handles renaming just fine with cherry-picks, no special options
necessary. (Well, there are probably corner cases, but it's code,
there are always corner cases!)
For git log, you'll want to add the --follow parameter if you're
asking for the history of a specific file or directory beyond a
renaming event.
git blame will show you the commit that renamed the file, by default,
but then you can request the revision prior to that using the commit
hash || '^', for example. git blame 2fb6cc90^ --
src/backend/parser/gram.y to work your way back through history.
--
Dan Scott
Laurentian University
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] plpgsql gram.y make rule
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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql gram.y make rule
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
