Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE - Mailing list pgsql-hackers

From Matt Miller
Subject Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE
Date
Msg-id 1166475205.24308.281048787@webmail.messagingengine.com
Whole thread Raw
In response to Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE
Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE
List pgsql-hackers
> > The [pgcluster-1.7.0rc1-patch] patch applies to the 8.2.0 tarball ...
> > However, the patch will not apply to cvs branch REL8_2_0.
>
> I've been told that the pgcluster patch patches some generated files
> (parse.h and other apparently).

Yes, I could not at first apply to REL8_2_0 because the patch file
wanted to patch src/backend/parser/gram.c.  At that point I started over
with a fresh REL8_2_0, ran "./configure; make", and tried the patch
again.  That's when I got a bunch of failures and fuzz.  The problem
files are:

src/backend/parser/gram.c
src/backend/parser/parse.h
src/interfaces/libpq/libpq.rc

So, I suppose libpq.rc is a derived file, also?

Now I have two questions.  First, why does pgcluster patch derived
files?  Is this just sloppy/lazy technique, or could there be some
deeper reason?  I realize this is properly to be posed to the pgcluster
folks, but they don't seem to be too responsive, at least not to their
pgfoundry forums.

Second, does it make sense that the derived files that rejected the
patch would be so different between the 8.2.0 tarball and my
REL8_2_0 build?


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: effective_cache_size vs units
Next
From: Tom Lane
Date:
Subject: Re: Typo in pg_dump documentation and new suggestion for Release Notes