| Age | Commit message (Collapse) | Author |
|---|
|
Submitted by: D'Arcy Cain
|
|
./utils/adt/varlena.c
- --- ../../../orig/postgres95/src/backend/utils/adt/varlena.c Mon Jul 22
23:56:04 1996
+++ ./utils/adt/varlena.c Tue Sep 17 15:12:55 1996
@@ -166,7 +166,7 @@
if (inputText == NULL)
return(NULL);
- - len = strlen(inputText) + VARHDRSZ;
+ len = strlen(inputText) + VARHDRSZ + 1 /* terminating 0 */;
result = (struct varlena *) palloc(len);
VARSIZE(result) = len;
memmove(VARDATA(result), inputText, len - VARHDRSZ);
Submitted by: skimo@breughel.ufsia.ac.be (Sven Verdoolaege)
|
|
of the array constants and in one of the loadable modules I posted some time
ago.
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
|
|
The comparison routines for text and char data type give incorrect results
if the input data contains characters greater than 127. As these routines
perform the comparison using signed char variables all character codes
greater than 127 are interpreted as less than 0. These codes are used to
encode the iso8859 char sets.
The other text-like data types seem to work as expected as they use unsigned
chars in comparisons.
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
|
|
- code compile tested, but due to a yet unresolved problem with
parse.h's creation, compile not completed...
|
|
|
|
|
|
Goals: reduce the difficulty of porting from platform to platform,
release to release, but moving as much as possible into config.h
|
|
conditions are always met. The patch can be applied to any version
of Postgres95 from 1.02 to 1.05. After applying the patch, queries
using indices on bpchar and varchar fields should (hopefully ;-) )
always return the same tuple set regardless to the fact whether
indices are used or not.
Submitted by: Gerhard Reithofer <tbr_laa@AON.AT>
|
|
|
|
---
below my signature, there are a coupls of diffs and files in a shell
archive, which were needed to build postgres95 1.02 on Siemens Nixdorfs
MIPS based SINIX systems. Except for the compiler switches "-W0" and
"-LD-Blargedynsym" these diffs should also apply for other SVR4 based
systems. The changes in "Makefile.global" and "genbki.sh" can probably
be ignored (I needed gawk, to make the script run).
There is one bugfix thou. In "src/backend/parser/sysfunc.c" the
function in this file didn't honor the EUROPEAN_DATES ifdef.
---
Submitted by: Frank Ridderbusch <ridderbusch.pad@sni.de>
|
|
Submitted by: Dan McGuirk <mcguirk@indirect.com>
|
|
and found out that one of the patches is a show stopper for
compiling under a strict ansi package.
Please make sure the following fix makes it into the 1.02.1
release...
Thanks.
-Kurt
|
|
Submitted by: darcy@druid.druid.com (D'Arcy J.M. Cain)
|
|
Submitted by: darcy@druid.druid.com (D'Arcy J.M. Cain)
|
|
fixes another complaint.
More fixes from Bruce...
|
|
|
|
- src/backend/access
- no changes
- src/backend/utils
- mostly cosmetic changes
- ESCAPE_PATCH Added
- src/Makefile.global changes merged
|
|
Submitted by: Randy Kunkee <kunkee@Starbase.NeoSoft.COM>
|
|
The updating of array fields is broken in Postgres95-1.01, An array can
be only replaced with a new array but not have some elements modified.
This is caused by two bugs in the parser and in the array utilities.
Furthermore it is not possible to update array with a base type of
variable length.
- submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
|
|
- submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
|
|
Select queries with an isnull or notnull clause, like "select * where
somefield isnull", crash the backend if the table has at least one index.
If the indices are deleted the queries work again. Also the explain
command fail in the same way.
The is caused by a bug in subroutine of the optimizer which doesn't check
null values in the clauses.
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
|
|
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>
|
|
|
|
submitted by: Bruce Momjian (root@candle.pha.pa.us)
|
|
varchar.diff
------------
This patch was necessary for the OpenLink Postgres Database Agent.
I think this fixes a bug anyway.
The following query demonstrates this bug:
create table foo (bar varchar);
insert into foo values (''); -- no problem
select * from foo where bar = ''; -- fails
|
|
causes segmentation fault.
Thanks to: Salvador Ortiz Garcia, Robert Patrick, Paul 'Shag' Walmsley,
and James Cooper for finding and fixing the problem.
|
|
|
