Bruce Momjian [Fri, 10 Jan 1997 17:40:07 +0000 (17:40 +0000)]
I found the following bugs in the version 6.0 (dated 961229).
At least the first two should be fixed before the final release of 6.0.
1) There is a mismatch between the type declared in the catalog for
the input/output attributes of pg_type and the actual type of
values stored in the table. The type of typinput, typoutput,
typsend and typreceive are declared oid (26) while the values are
regproc (24). The error was there also in previous versions but
nobody noticed it until an Assert has been added in ExecEvalVar.
The effect is that it is now impossible to replace the typoutput
of existing data types with new procs.
2) The identd hba fails after the first time because the data read
from the identd socket is not zero-terminated and strlen reports
an incorrect length if the stack contains garbage, which usually
happens after the first connection has been made.
3) The new initdb wants to create itself the data directory. This
implies that the parent directory must be writable by postgres and
this may not always be desirable. A better solution would be to
allow the directory to be created by root and then filled by initdb.
It would also nice to have some reasonable default for PGLIB and
PGDATA like the previous version did. This applies also to the
postmaster executable.
counting the empty dummy queries in libpq isn't everything.
If the backend sends an error, the I returns from the dummies
still come. So we must eat them up in any case, not just
returning on the occurence of an E reply.
PORT NeXT requires an isascii() define...put it in config.h, most likely
*should* have gone into the ports directory, but hopefully *someday* we'll
be able to get rid of that?
Submitted by: "Martin J. Laubach" <mjl@wwx.vip.at>
NOTE: The following patch I was uncertain of, but applied it...will end up
testing the compile on my machine later tonight anyway, but if anyone
knows why this *shouldn't* have been done, please change it. (CC -> LD)
someone added pg_listen and pg_notifies to libpgtcl. But first
these routines try to use the old pointer casting stuff to get
the connection id, second the notification hash table should
be part of the cliendData. Otherwise, one interpreter might
eat up the notifies for another one.
Please apply the patch below to the current 6.0 tree.
Bruce Momjian [Sat, 28 Dec 1996 02:22:12 +0000 (02:22 +0000)]
Here is a bug fix and some spelling changes for the complex number tutorial
code. I have also written a complete complex number package based on this
tutorial; I will submit this as a contribution soon. Is there a particular
format for contributed tar files? I have a C source file, two SQL files, and a
Makefile.
Vadim B. Mikheev [Fri, 27 Dec 1996 13:13:58 +0000 (13:13 +0000)]
There was JMP_BUF defined in config.h. And SIGJMP_BUF later.
And now - JMP_BUF again. Is it enough, folks ?
Fixed again:
cc1: warnings being treated as errors
exc.c: In function 'ExcRaise':
exc.c:187: warning: passing arg 1 of 'Longjmp' from incompatible pointer type
gmake[3]: *** [exc.o] Error 1
Bruce Momjian [Thu, 26 Dec 1996 17:47:42 +0000 (17:47 +0000)]
I have this annoying habit (among others) of putting
%ud in a printf format strings instead of just %u.
There were three occurances of this in catalog_utils.c,
two in parser.c and one in rewriteSupport.c in the oid
patch that I submitted and was applied. They won't crash
anything, but the error messages will have a 'd' after the
Oid. Annoying, but none are db-threatening.
Sorry about that folks...I'll be more careful in the future...
Bruce Momjian [Thu, 26 Dec 1996 17:46:07 +0000 (17:46 +0000)]
In src/backend/catalog/pg_operator.c in OperatorDef, there
are three SearchSysCacheTuple(PRONAME,...) calls that use three
different macros to convert the typeId array of Oids.
Bruce Momjian [Thu, 26 Dec 1996 17:44:46 +0000 (17:44 +0000)]
Removal of CppConcat from indexam.c.
As an example I sent a bug-report on 26 Nov to tell that the fix included
below is necessary to compile pg95-current on Ultrix with Digital's
standard C compiler c89. In fact I think that this fix is needed
for any C compiler sticking very close the standard, see my discussion
in the original bug report.