varlena.c - part of Thomas' most recent patch

Subject: [HACKERS] locale patches !

Hi there,

here are little patches to get Postgres 6.1 works with locale stuff.
This is a patch against 970402.tar.gz, there are no problem to apply them
by hand to 6.0 release. Collate stuff tested about 1-2 months in real
working database but I'm sure there must be no problem. US hackers
could vote against locale implementation ( locale for sure will affect to
speed of postgres ), so I introduce variable USE_LOCALE which
controls locale stuff. Non-US users now could use ~* operator
for searching and <order by> for strings with nation alphabet.
Please, don't forget, as I did first time, to set environment variable
LC_CTYPE and LC_COLLATE because backend get locale information from them.
I start postmaster from a little script, assuming that shell is Bash shell
it looks like:

#!/bin/sh

export LC_CTYPE=koi8-r
export LC_COLLATE=koi8-r
postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'

./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)

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>

        - src/backend/access
                - no changes
        - src/backend/utils
                - mostly cosmetic changes
                - ESCAPE_PATCH Added
        - src/Makefile.global changes merged

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>