Good, added to pginclude/README:
Also, tests should be done with configure settings of --enable-cassert
and EXEC_BACKEND on and off.
I think we had more problems this time just because our code is more
complex.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> FYI, 527 include were removed from non-header C files in this run. That
> is not something that can be easily done manually.
It's not so easily done automatically, either :-(. I'm not sure why
this go-round was so much more painful than the last, but i
FYI, I updated pginclude/README to explain the complexity of
removing includes from include files:
pgfixinclude
sort include references
run multiple times:
pgcompinclude
pgrminclude /src/include
pgrminclude /
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote:
>> I would like to propose that we revert all the include-related changes
>> of the past two days, and that src/tools/pginclude be removed from the
>> CVS tree, until such time as it is rewritten to be much
Martijn van Oosterhout writes:
> On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote:
>> After some reflection it seems that there is only one case where removal
>> of a needed include file would not lead to a compiler error or warning,
>> assuming gcc with ordinary -W settings (notably -Wmis
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW, one of the remaining holes in pgrminclude is that it compiles with
>> -fsyntax-only, which apparently causes it to fail to detect some errors
>> of significance --- I assume that's how it managed to foul up lmgr.c,
>> inet_net_ntop
On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote:
> I would like to propose that we revert all the include-related changes
> of the past two days, and that src/tools/pginclude be removed from the
> CVS tree, until such time as it is rewritten to be much smarter about
> what it is doing.
Rather th
On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote:
> After some reflection it seems that there is only one case where removal
> of a needed include file would not lead to a compiler error or warning,
> assuming gcc with ordinary -W settings (notably -Wmissing-prototypes).
> That case is exac
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> BTW, one of the remaining holes in pgrminclude is that it compiles with
> >> -fsyntax-only, which apparently causes it to fail to detect some errors
> >> of significance --- I assume that's how it managed to foul u
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote:
> >> I would like to propose that we revert all the include-related changes
> >> of the past two days, and that src/tools/pginclude be removed from the
> >> CVS tree, until such time as
Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >
> >>I agree with reverting. The tool looks pretty broken anyway, with
> >>hardcoded paths and all sorts of stuff quite apart from logic problems.
> >>
> >>
> >
> >Well, it's only intended to work
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote:
> >> After some reflection it seems that there is only one case where removal
> >> of a needed include file would not lead to a compiler error or warning,
> >> assuming gcc with ordinary
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I agree with reverting. The tool looks pretty broken anyway, with
hardcoded paths and all sorts of stuff quite apart from logic problems.
Well, it's only intended to work on Bruce's system, so until someone
else takes over the
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I agree with reverting. The tool looks pretty broken anyway, with
> hardcoded paths and all sorts of stuff quite apart from logic problems.
Well, it's only intended to work on Bruce's system, so until someone
else takes over the position of chief grunt
Tom Lane wrote:
In combination with the amount of time wasted over the past two days,
it is now perfectly clear that the existing pginclude tools are not
NEARLY good enough to detect what they are breaking. I would like to
propose that we revert all the include-related changes of the past two
d
Kris Jurka <[EMAIL PROTECTED]> writes:
> The inclusion of access/tuptoaster.h in access/common/indextuple.c brought
> in the define of TOAST_INDEX_HACK which compresses large index entries.
> When this was removed the entries were no longer compressed which caused
> btree_gist to fail.
This is
16 matches
Mail list logo
