>
> Please apply this HAVING regression patch.
> > My bad. It is caused by a known bug having to do with GROUP BY.
It ain't$
> > nothing to do with HAVING. For some reason the bug went away for a
while, $
> > script. It must have, because that is how I created the expected
file. :(
> >
> > A patch to the regression will be forthcoming.
>
Attached to the mail is locale-patch.tar.gz. In the archive
there are:
file README.locale
short description
directory src/test/locale
test suite; currently only koi8-r tests, but the suite can be
easily extended
file locale.patch
the very patch; to apply: patch < locale.patch; should be applied
to postgres-6.3.2 (at least I created it with 6.3.2 without any
additional
patches)
Files touched by the patch: src/include/utils/builtins.h
src/backend/utils/adt/char.c src/backend/utils/adt/varchar.c
src/backend/utils/adt/varlena.c
Oleg
Hi, here are patches I promised (against 6.3.2):
* character_length(), position(), substring() are now aware of
multi-byte characters
* add octet_length()
* add --with-mb option to configure
* new regression tests for EUC_KR
(contributed by "Soonmyung. Hong" <hong@lunaris.hanmesoft.co.kr>)
* add some test cases to the EUC_JP regression test
* fix problem in regress/regress.sh in case of System V
* fix toupper(), tolower() to handle 8bit chars
note that:
o patches for both configure.in and configure are
included. maybe the one for configure is not necessary.
o pg_proc.h was modified to add octet_length(). I used OIDs
(1374-1379) for that. Please let me know if these numbers are not
appropriate.
For substr() and substring() on the text data type, the relevant code is in
varlena.c. You are right, there is a problem. I have a patch which I will
apply to the source tree soon. The copy enclosed below probably does not
preserve tabs correctly so cannot be applied directly; the relevant change
is simply changing the ">=" to ">"...
What it does:
It solves stupid problem with cyrillic charsets IP-based on-fly recoding.
take a look at /data/charset.conf for details.
You can use any tables for any charset.
Tables are from Russian Apache project.
Tables in this patch contains also Ukrainian characters.
Then run ./configure --enable-recode
Here are patches which should help fix timezone problems in the
datetime and abstime code. Also, I repatched varlena.c to add in
some comments and a little error checking on top of Vadim's earlier
repairs. There are slight mods to the circle data type to have the
distance operator between circles measure the distance between
closest points rather than between centers.
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'
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>
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>
Bruce Momjian