However somebody else also applied a patch to the same part of
configure to fix a different problem. So part of my patch was not
applied or got reversed or ... whatever.

The attached patch will restore configure --with-tcl to working
order and should remove a lot of the messages complaining about
tcl not working.

Alvin

After applying the following patch there remain two
probable buffer overruns detected by Electric Fence during
the regression test.
I'll try find out what causes the remain two ones.

This patch also corrects a typo in smgr.c.

or ORDER BY bug.

3) Add "#include "config.h" to src/interfaces/ecpg/preproc/pgc.l
   to correct "strings.h not found".  config.h has the proper define to
   make this work and should probably be near the top of pgc.l before
   the first include.

2) Add "#define gettimeofday(a,b) gettimeofday(a) to src/include/config.h
        On the 88k SVR4, gettimeofday only has one argument.  This is
        checked for in a few other packages by configure, so there should
        be some examples of the configure test out there.

was detected by Electric Fence and triggered by statements like:

	SELECT * into table t from pg_database;

The system would crash on a memmove call in DataFile() with arguments
like this:

	memmove(0x0, 0x0, 0);

Maurice Gittens

was a 2000 character buffer allocated for results, and the files
you refer to produce a 2765 byte column called formsource.  This
should not have worked with any version of libpgtcl.

Nevertheless, the limit is an artificial one, since there is no
need to use this intermediate buffer where it is being used and
abused.

Randy Kunkee <kunkee@pluto.ops.NeoSoft.com>

1. Remove the char2, char4, char8 and char16 types from postgresql
2. Change references of char16 to name in the regression tests.
3. Rename the char16.sql regression test to name.sql.  4. Modify
the regression test scripts and outputs to match up.

Might require new regression.{SYSTEM} files...

Darren King

access overrun. For the sake of doing things properly here is a
patch which fixes it.

This patch is for the file backend/commands/sequence.c.

Maurice Gittens

yyerror ones from bison. It also includes a few 'enhancements' to
the C programming style (which are, of course, personal).

The other patch removes the compilation of backend/lib/qsort.c, as
qsort() is a standard function in stdlib.h and can be used any
where else (and it is). It was only used in
backend/optimizer/geqo/geqo_pool.c, backend/optimizer/path/predmig.c,
and backend/storage/page/bufpage.c

> > Some or all of these changes might not be appropriate for v6.3,
since we > > are in beta testing and since they do not affect the
current functionality.  > > For those cases, how about submitting
patches based on the final v6.3 > > release?

There's more to come. Please review these patches. I ran the
regression tests and they only failed where this was expected
(random, geo, etc).

Cheers,

Jeroen

sequential scans! (I think it will also work with hash, index, etc
but I did not check it out! I made some High level changes which
should work for all access methods, but maybe I'm wrong. Please
let me know.)

Now it is possible to make queries like:

select s.sname, max(p.pid), min(p.pid) from part p, supplier s
where s.sid=p.sid group by s.sname having max(pid)=6 and min(pid)=1
or avg(pid)=4;

Having does not work yet for queries that contain a subselect
statement in the Having clause, I'll try to fix this in the next
days.

If there are some bugs, please let me know, I'll start to read the
mailinglists now!

Now here is the patch against the original 6.3 version (no snapshot!!):

Stefan

a dumpall.  This has been happening when a second \connect is
encountered.

The faulty code was in fe-connect.c, where the memory for the user
password was freed, but the pointer itself was not set to NULL.
Later, the memory was reused and the password appeared not to be
empty, so that an attempt was made to reference it.

Oliver Elphick

another tcl/tk patch

variable that can be set in one place to affect everything...

From: Andreas Klemm <andreas@klemm.gtn.com>

From: Vince Vielhaber <vev@michvhf.com>