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 resu
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. F
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 ch
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.
> >>
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 al
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
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
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 (
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 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 b
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?
--
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
+--+--+--
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
++--
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) <-> ı
İ
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"
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 gl
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, R
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 u
Peter Eisentraut 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 them, and g
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 kee
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 ca
Guillaume Smet wrote:
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane 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
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane 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 common locales,
Andrew Dunstan 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 locale from its en
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 loses
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). I
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 cov
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 f
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 ad
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 out
29 matches
Mail list logo
