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: Postgres Hackers List <hackers(at)postgreSQL(dot)org>
Subject: Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Date: 1999-03-03 16:52:34
Message-ID: 36DD68D2.E5583B4B@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I don't think it's cvs' fault.
> I'm using cvs 1.10 here, but I don't think its behavior has changed
> in this respect in any recent version. If it did not timestamp
> updates with time of retrieval, it would create synchronization bugs
> with respect to locally created files, which'd be no fun either.

I use CVSup, and it seems to keep the creation date of files consistant
with the source cvs tree. Does anonymous cvs not do that? Again, I
*don't* see the behavior that you do, at least given my CVSup/cvs-1.9
system.

> PS: treating gram.c as a derived file that is made while building
> a tarball would also eliminate our recurring problem with gram.c
> appearing to be out-of-date in releases, when it really isn't.

Sure. Who wants to work that out?

btw, could all of this be traced to bad dependencies on parse.h? Our
current Makefile system does not do this correctly. I applied some small
patches recently to help, but it did not fix the fundamental problem
that all the backend/* directories refer to backend/parse.h, but they do
not know that backend/parse.h is a copy of backend/parser/parse.h.

- Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kaare Rasmussen 1999-03-03 18:33:55 Re: [HACKERS] NUMERIC and Perl
Previous Message Jan Wieck 1999-03-03 15:44:18 Re: [HACKERS] palloc.h again