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

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, Postgres Hackers List <hackers(at)postgreSQL(dot)org>
Subject: Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Date: 1999-03-03 14:41:36
Message-ID: 36DD4A20.CF8FC02D@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1999-03-03 14:49:20 Re: [HACKERS] int 8 on FreeBSD
Previous Message The Hermit Hacker 1999-03-03 14:39:59 Re: [HACKERS] int 8 on FreeBSD