Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c' - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Date
Msg-id 36DD4A20.CF8FC02D@alumni.caltech.edu
Whole thread Raw
In response to Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
List pgsql-hackers
> >> I didn't forget! istm that we risk cvs bloat by checking in derived
> >> files like gram.c,
> Well, if you want to know why I was annoyed, I'll explain.
> On my machine, gram.c/parse.h appeared to be newer than gram.y.
> Since gram.c/parse.h were in fact *not* up-to-date with respect
> to header-file changes elsewhere, they didn't compile.

Oh! I haven't seen that behavior before, and am not sure why you did :(
If I updated gram.y, but did not update gram.c, then cvs and CVSup
should never bollix up the times on the files afaik.

Sorry for the diversion, but I'm confused as to how you got this
symptom. Been doing this for a couple of years now, and doing a *lot*
with gram.y so if it was a checkin or sync problem I would have expected
to see it before this.

btw, one of the changes I made was to move the backend/parser/ build to
earlier in the build list, since when debugging is enabled the node
printing functions (now) need to see the definitions of some of the
parser nodes. I wonder if somehow that was involved??
                     - Tom


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] int 8 on FreeBSD
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] int 8 on FreeBSD