Andrew Dunstan píše v so 31. 01. 2009 v 17:08 -0500:
Zdenek Kotala wrote:
PL-check gives the diff below on PLTCL tests under en_US locale. I guess
the simplest answer is to add an alternative result file.
Yes, I thought about add locale suffix for alternative result file, but
Zdenek Kotala wrote:
PL-check gives the diff below on PLTCL tests under en_US locale. I guess
the simplest answer is to add an alternative result file.
Yes, I thought about add locale suffix for alternative result file, but
it could be useless overhead.
But some tests can be modified.
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 23. 01. 2009 v 23:57 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple
Andrew Dunstan píše v pá 23. 01. 2009 v 23:57 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple change.
Will be
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple change.
Will be possible to set more locales and run tests without recompilation
on
Devrim GÜNDÜZ wrote:
Yep, I ran them already, and as you wrote, I'm getting 3 errors (tsearch
tests + foreign_data test).
And then use your language skills to determine what the correct
behavior is. ;-)
SKIES would be skıes (dotless i).
Here is the conversion table:
I (capital) - ı
İ
I think the test show that there is a bug in the tsearch support for
Turkish. Here is the test diff:
How to reproduce that?
% psql -l
List of databases
Name| Owner | Encoding | Collation |Ctype| Access privileges
On Mon, 2009-01-19 at 20:45 +0300, Teodor Sigaev wrote:
How to reproduce that?
-bash-3.2$ psql -l
List of databases
Name| Owner | Encoding | Collation |Ctype| Access
Privileges
5 of 120 tests failed.
This is on a Fedora-9 x86 box, and:
-bash-3.2$ rpm -qv glibc
glibc-2.8-8.i686
Interesting. On my notebook all is ok.
% uname -a
FreeBSD ... 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2
Is any possibility of broken locale?
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Guillaume Smet wrote:
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the
de facto policy is that we try to keep them passing in locales that
are used by any of the regular developers. I think it
Peter Eisentraut píše v ne 11. 01. 2009 v 12:54 +0200:
The remaining 80 failures are more-or-less linguistic issues that belong to
the following 26 language/country combinations:
cs_CZ sorts ch separately; sorts st = s
s st
Zdenek
--
Sent via pgsql-hackers mailing list
On Monday 19 January 2009 22:39:30 Zdenek Kotala wrote:
Peter Eisentraut píše v ne 11. 01. 2009 v 12:54 +0200:
The remaining 80 failures are more-or-less linguistic issues that belong
to the following 26 language/country combinations:
cs_CZ sorts ch separately; sorts st = s
s
Teodor Sigaev wrote:
5 of 120 tests failed.
This is on a Fedora-9 x86 box, and:
-bash-3.2$ rpm -qv glibc
glibc-2.8-8.i686
Interesting. On my notebook all is ok.
% uname -a
FreeBSD ... 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2
Is any possibility
Devrim GÜNDÜZ wrote:
On Sun, 2009-01-11 at 11:46 -0500, Tom Lane wrote:
If we try to fix those cases I think we should try to fix Turkish i
as well ... but I concur that first requires determining if it's
behaving wrong or not. Devrim, or someone?
What exactly do you want to see?
Using a
Hi,
On Mon, 2009-01-12 at 12:06 +0200, Peter Eisentraut wrote:
Using a glibc system, initdb with --locale=tr_TR (or tr_TR.utf8 or
whatever) and run make installcheck. You should see test failures in
the tsearch and tsdicts tests that appear to relate to issues with
lowercasing the I
On Friday 09 January 2009 16:51:44 Peter Eisentraut wrote:
Heikki Linnakangas wrote:
The foreign_data test case is failing when I run make installcheck
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
I have removed one of the differences but can't
On Friday 09 January 2009 18:24:55 Tom Lane wrote:
I don't think we are prepared to buy into a general policy that the
regression tests should pass in *any* locale; maintaining a large
number of variant expected-files isn't very practical. However, the
de facto policy is that we try to keep
Peter Eisentraut pete...@gmx.net writes:
This called for an extensive test ... :-)
My glibc installation supplies 668 locales (locale -a), which appear to
represent about 225 distinct language/country combinations. (The rest are
encoding variants.)
I ran the regression tests with all of
On Sun, 2009-01-11 at 12:54 +0200, Peter Eisentraut wrote:
The Turkish i failures are in the tsearch tests. I'm not completely
comfortable that it's doing the right thing there.
AFAIK, ISO-8859-9 is broken in a way, and the Turkish maintainers are
not interested in fixing them -- they ask us
On Sun, 2009-01-11 at 11:46 -0500, Tom Lane wrote:
If we try to fix those cases I think we should try to fix Turkish i
as well ... but I concur that first requires determining if it's
behaving wrong or not. Devrim, or someone?
What exactly do you want to see?
Regards,
--
Devrim GÜNDÜZ,
The foreign_data test case is failing when I run make installcheck
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
The reason is the different ordering of upper and lower case characters,
per attached diff file. We can simply add an alternative expected
Heikki Linnakangas wrote:
The foreign_data test case is failing when I run make installcheck
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
The reason is the different ordering of upper and lower case
characters, per attached diff file. We can simply add
Andrew Dunstan wrote:
Regression tests have always failed on non-C locales AFAIK. The
buildfarm goes out of its way to avoid that.
The regression tests should work just fine in non-C locales. If the
buildfarm goes out of its way to avoid non-C locales, then it loses some
significant code
Heikki Linnakangas wrote:
The foreign_data test case is failing when I run make installcheck
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
I have removed one of the differences but can't reproduce the other
right now (although it looks consequential).
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
The foreign_data test case is failing when I run make installcheck
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
The reason is the different ordering of upper and lower case
characters, per attached diff
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Regression tests have always failed on non-C locales AFAIK. The
buildfarm goes out of its way to avoid that.
The regression tests should work just fine in non-C locales. If the
buildfarm goes out of its way to avoid non-C locales, then it
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
The regression tests should work just fine in non-C locales.
It was discussed here at the time, IIRC, and we put in the check
precisely because other locales broke the buildfarm. Originally
buildfarm just inherited the
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the
de facto policy is that we try to keep them passing in locales that
are used by any of the regular developers. I think it would be useful
to have buildfarm members testing in a few common locales.
If you define
Guillaume Smet wrote:
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the
de facto policy is that we try to keep them passing in locales that
are used by any of the regular developers. I think it would be useful
to have buildfarm members testing in a few common
29 matches
Mail list logo
