709 Commits (4cb824699e12c39fad97fb3d9085ced0d14c067c)

Author	SHA1	Message	Date
Marc G. Fournier	f8009e1786	The remainder of D'Arcy's changes, most notibly the usage of SIGNAL_ARGS	29 years ago
Marc G. Fournier	906651f663	There is a bug in the function executor. The backend crashes while trying to ... execute an sql function containing an utility command (create, notify, ...). The bug is part in the planner, which returns a number of plans different than the number of commands if there are utility commands in the query, and in part in the function executor which assumes that all commands are normal query commands and causes a SIGSEGV trying to execute commands without plan. Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>	29 years ago
Marc G. Fournier	796f78998e	Fixes: ... The problem is that the function arguments are not considered as possible key candidates for index scan and so only a sequential scan is possible inside the body of a function. I have therefore made some patches to the optimizer so that indices are now used also by functions. I have also moved the plan debug message from pg_eval to pg_plan so that it is printed also for plans genereated for function execution. I had also to add an index rescan to the executor because it ignored the parameters set in the execution state, they were flagged as runtime variables in ExecInitIndexScan but then never used by the executor so that the scan were always done with any key=1. Very odd. This means that an index rescan is now done twice for each function execution which uses an index, the first time when the index scan is initialized and the second when the actual function arguments are finally available for the execution. I don't know what is the cost of an double index scan but I suppose it is anyway less than the cost of a full sequential scan, at leat for large tables. This is my patch, you must also add -DINDEXSCAN_PATCH in Makefile.global to enable the changes. Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>	29 years ago
Marc G. Fournier	c3673c0345	More run-time checking errors: ... -Kurt	29 years ago
Marc G. Fournier	bb0bdfd101	Fixes: ... 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>	29 years ago
Marc G. Fournier	5108a5b320	More merges from Dr. George's tree... ... - src/backend/tcop/* - cosmetic changes to OPENLINK patches - src/backend/storage/* - more changes, mostly cosmetic - src/backend/ports/* - merge in patches for aix and i386_solaris	29 years ago
Marc G. Fournier	9bffaade96	Fixes: ... This is a patch to prevent an endless loop occuring in the Postgres backend when a 'warning' error condition generates another warning error contition in the handler code. Submitted by: Chris Dunlop, <chris@onthe.net.au>	29 years ago
Marc G. Fournier	faf21935d1	fsync patch from openlink	29 years ago
Marc G. Fournier	d31084e9d1	Postgres95 1.01 Distribution - Virgin Sources	29 years ago