- 10 Aug, 1996 1 commit
-
-
Marc G. Fournier authored
Submitted by: darcy@druid.druid.com (D'Arcy J.M. Cain)
-
- 09 Aug, 1996 1 commit
-
-
Marc G. Fournier authored
Submitted by: Dan McGuirk <mcguirk@indirect.com>
-
- 06 Aug, 1996 8 commits
-
-
Julian Assange authored
problem in psql
-
Marc G. Fournier authored
Also, I think that an extra source of noise in the diff of regress.out and expected.out is caused by not substituting the shared library file extension in the regression.input file (much like the paths and the usernames are sub'ed). This seems to be fixed with the following patches to regression.input and the Makefile... If I'm off base here, please tell! Submitted by: Wayde Nie <niew@phoenix.cis.mcmaster.ca>
-
Marc G. Fournier authored
I've enclosed two patches. The first affects Solaris compilability. The bug stems from netdb.h (where MAXHOSTNAMELEN is defined on a stock system). If the user has installed the header files from BIND 4.9.x, there will be no definition of MAXHOSTNAMELEN. The patch will, if all else fails, try to include <arpa/nameser.h> and set MAXHOSTNAMELEN to MAXDNAME, which is 256 (just like MAXHOSTNAMELEN on a stock system). The second patch adds aliases for "ISNULL" to "IS NULL" and likewise for "NOTNULL" to "IS NOT NULL". I have not removed the postgres specific ISNULL and NOTNULL. I noticed this on the TODO list, and figured it would be easy to remove. The full semantics are: [ expression IS NULL ] [ expression IS NOT NULL ] --Jason Submitted by: Jason Wright <jason@oozoo.vnet.net>
-
Marc G. Fournier authored
Previously Postgres95 wouldn't accept 'order by' clauses with fields referred to as '<table>.<field>', e.g.: select t1.field1, t2.field2 from table1 t1, table2 t2 order by t2.field2; This syntax is required by the ODBC SQL spec. Submitted by: Dan McGuirk <mcguirk@indirect.com>
-
Marc G. Fournier authored
While a normal SELECT statement can contain a GROUP BY clause, a cursor declaration cannot. This was not the case in PG-1.0. Was there a good reason why this was changed? Are cursors being phased out? Is there any way to get data with just a SELECT (and without a DECLARE CURSOR ...)? The patch below seems to fix things. If anyone can see a problem with it, please let me know. Thanks. Submitted by: David Smith <dasmith@perseus.tufts.edu>
-
Marc G. Fournier authored
Here are a few minor fixes to Postgres95. Mostly I have added const to some of the char pointers. There was also a missing header file and a place where it looks like "==" was used when "=" was meant. I also changed some variables from Pfin and Pfout tp pfin and pfout because the latter shadow global variables and that just seems like an unsafe practice which I like to avoid. Submitted by: "D'Arcy J.M. Cain" <darcy@druid.druid.com>
-
Marc G. Fournier authored
Submitted by: Andrew Martin <martin@biochemistry.ucl.ac.uk>
-
Julian Assange authored
for slash commands)
-
- 05 Aug, 1996 1 commit
-
-
Marc G. Fournier authored
Someone asked me if the bpchar type could be extended to do case-insensitive regular expression searches. Submitted by: "Alistair G. Crooks" <azcb0@juts.ccc.amdahl.com>
-
- 04 Aug, 1996 2 commits
-
-
Marc G. Fournier authored
submitted by: "Peter Daum" <gator@cs.tu-berlin.de>
-
Marc G. Fournier authored
-
- 02 Aug, 1996 2 commits
-
-
Marc G. Fournier authored
README file for regresssion tests from Dr. George
-
Marc G. Fournier authored
-
- 01 Aug, 1996 5 commits
-
-
Marc G. Fournier authored
make TCL conditinal compilation work Submitted by: Dr_George_D_Detlefsen <drgeorge@madmax.ilt.com>
-
Marc G. Fournier authored
Originally, I thought the problem was caused by a function that gets called as a normal function where we want to return a value, and as a signal handler where we need to have it accept a parameter (the signal number) and it returns nothing, I was going to case the function name in the signal call as (void (*)(int)). Looking at all the source, it turns out this function only gets used as a signal handler, so I set an int parameter and return void. I have removed the Linux defines because they are not needed. BSD let this sloppiness slide. Linux gave a compile error. Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
-
Marc G. Fournier authored
Suggested by: Michael Babcock <michael@kanji.com>
-
Marc G. Fournier authored
Submitted by: Dr. George
-
Marc G. Fournier authored
Submitted by: Dr. Geoge
-
- 31 Jul, 1996 16 commits
-
-
Marc G. Fournier authored
-
Marc G. Fournier authored
Submitted by: Dr_George_D_Detlefsen <drgeorge@madmax.ilt.com>
-
Marc G. Fournier authored
fixes another complaint. More fixes from Bruce...
-
Marc G. Fournier authored
-
Marc G. Fournier authored
-
Marc G. Fournier authored
Submitted by: Bruce
-
Marc G. Fournier authored
Suggested by: Daniel Kalchev <daniel@digsys.bg>
-
Marc G. Fournier authored
-
Marc G. Fournier authored
#include <sys/termios.h> Submitted by: Dr. George
-
Marc G. Fournier authored
-
Marc G. Fournier authored
-
Marc G. Fournier authored
Submitted by: Dr_George_D_Detlefsen <drgeorge@ilt.com>
-
Marc G. Fournier authored
In postgres95/src/backend/nodes/readfuncs, lines 1188 and 1189, local_node->relname is taken to point to a NameType, while its defined as a pointer to char. Both the casting to Name and the call of namestrcpy should, IMHO, be changed appropriately (first patch). As far as I could see from the Linux signal header file, a signal handler is declared as typedef void (*__sighandler_t)(int); Few changes to postgres95/src/backend/storage/lmgr/proc.c seem appropriate to comply with this. Finally, postgres95/src/bin/pg_version/pg_version.c defines a function GetDataHome (by default, returning an integer) and returns NULL in the function, which isn't an integer... Submitted by: ernst.molitor@uni-bonn.de
-
Marc G. Fournier authored
updates the psql.1 manual page for \ options add row count and ties it to the header option updated manual pages and comment for above change got \? to display in one screen-full (almost, \? scrolls off top) moved \r to \E, and \z to \r (for historical reasons with monitor) small code alignment cleanup Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
-
Marc G. Fournier authored
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
-
Marc G. Fournier authored
Submitted by: Dan McGuirk <mcguirk@indirect.com>
-
- 30 Jul, 1996 3 commits
-
-
Marc G. Fournier authored
> INDEXED searches in some cases DO NOT WORK. > Although simple search expressions (i.e. with a constant value on > the right side of an operator) work, performing a join (by putting > a field of some other table on the right side of an operator) produces > empty output. > WITHOUT indices, everything works fine. > submitted by: "Vadim B. Mikheev" <root@ais.sable.krasnoyarsk.su>
-
Marc G. Fournier authored
-
Marc G. Fournier authored
-
- 29 Jul, 1996 1 commit
-
-
Marc G. Fournier authored
declaration is incorrect. -Kurt
-