Skip site navigation (1) Skip section navigation (2)

Re: plpgsql gram.y make rule

From: Dan Scott <denials(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: plpgsql gram.y make rule
Date: 2012-09-25 04:23:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Sep 24, 2012 at 10:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?)

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

In response to

pgsql-hackers by date

Next:From: Hitoshi HaradaDate: 2012-09-25 05:11:14
Subject: Re: Oid registry
Previous:From: Rural HunterDate: 2012-09-25 04:22:43
Subject: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group