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'
|
Список | 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 по дате отправления: