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

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Дата
Msg-id 36DD4A20.CF8FC02D@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] int 8 on FreeBSD
Следующее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] int 8 on FreeBSD