rules regression test failed on mingw
Hi,
i'm seeing a fail in the rules regression, seems like it is not
ordering the results right even when the regression has an explicit
order by...
i'm in a mingw32 5.1 on xp sp2 using msys 1.0.10 and gcc 3.4.2
attached the regression.diffs
please make me know if i can provide more info
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Attachments:
regression.diffsapplication/octet-stream; name=regression.diffsDownload
*** C:/msys/1.0/home/Administrador/pgsql/src/test/regress/expected/rules.out Sun Nov 9 16:24:33 2008
--- C:/msys/1.0/home/Administrador/pgsql/src/test/regress/results/rules.out Mon Dec 15 08:32:03 2008
***************
*** 414,422 ****
----------------------+--------------+------------+------------+------------
gates | t | fired | $0.00 | $80,000.00
gates | t | hired | $80,000.00 | $0.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(5 rows)
insert into rtest_empmass values ('meyer', '4000.00');
--- 414,422 ----
----------------------+--------------+------------+------------+------------
gates | t | fired | $0.00 | $80,000.00
gates | t | hired | $80,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(5 rows)
insert into rtest_empmass values ('meyer', '4000.00');
***************
*** 431,439 ****
maier | t | hired | $5,000.00 | $0.00
mayr | t | hired | $6,000.00 | $0.00
meyer | t | hired | $4,000.00 | $0.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(8 rows)
update rtest_empmass set salary = salary + '1000.00';
--- 431,439 ----
maier | t | hired | $5,000.00 | $0.00
mayr | t | hired | $6,000.00 | $0.00
meyer | t | hired | $4,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(8 rows)
update rtest_empmass set salary = salary + '1000.00';
***************
*** 449,457 ****
mayr | t | honored | $7,000.00 | $6,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(11 rows)
delete from rtest_emp using rtest_empmass where rtest_emp.ename = rtest_empmass.ename;
--- 449,457 ----
mayr | t | honored | $7,000.00 | $6,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(11 rows)
delete from rtest_emp using rtest_empmass where rtest_emp.ename = rtest_empmass.ename;
***************
*** 469,477 ****
meyer | t | fired | $0.00 | $5,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(14 rows)
--
--- 469,477 ----
meyer | t | fired | $0.00 | $5,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(14 rows)
--
======================================================================
"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
i'm seeing a fail in the rules regression, seems like it is not
ordering the results right even when the regression has an explicit
order by...
What locale is this running in?
regards, tom lane
On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
i'm seeing a fail in the rules regression, seems like it is not
ordering the results right even when the regression has an explicit
order by...What locale is this running in?
Seems this is Spanish_Spain.1252 and the encoding WIN1252
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What locale is this running in?
Seems this is Spanish_Spain.1252 and the encoding WIN1252
What it looks like is that the locale is intentionally sorting h after k
(or more likely the rule is ch after ck). My Spanish is just about gone
... is that a sane behavior at all?
regards, tom lane
On Mon, Dec 15, 2008 at 10:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What it looks like is that the locale is intentionally sorting h after k
(or more likely the rule is ch after ck). My Spanish is just about gone
... is that a sane behavior at all?
not at all... where can i check those rules?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
On Mon, Dec 15, 2008 at 10:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What it looks like is that the locale is intentionally sorting h after k
(or more likely the rule is ch after ck). My Spanish is just about gone
... is that a sane behavior at all?
not at all... where can i check those rules?
Well, one thing you should try is
select 'wieck'::text < 'wiech'::text;
select 'wieck'::text > 'wiech'::text;
just to confirm whether the comparisons are actually working that way
or we've got some other issue. You could also try initdb'ing in other
locales to see if the behavior changes.
I have no idea how to poke into the internals of Windows' locale
definitions.
regards, tom lane
Tom Lane wrote:
"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What locale is this running in?
Seems this is Spanish_Spain.1252 and the encoding WIN1252
What it looks like is that the locale is intentionally sorting h after k
(or more likely the rule is ch after ck). My Spanish is just about gone
... is that a sane behavior at all?
It was sane behavior a couple of decades ago -- dictionaries used to
sort like this ("ch" was considered an independent letter, and sorted
between c and d). I'm not sure if RAE did actually revoke this
behavior, or it's just that us are now too used to the idea that it's
obsolete. If the former, we should be complaining to the glibc
developers. If the latter, we should complain to our school Spanish
teachers ;-)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, Dec 15, 2008 at 10:26 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
Tom Lane wrote:
"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What locale is this running in?
Seems this is Spanish_Spain.1252 and the encoding WIN1252
What it looks like is that the locale is intentionally sorting h after k
(or more likely the rule is ch after ck). My Spanish is just about gone
... is that a sane behavior at all?It was sane behavior a couple of decades ago -- dictionaries used to
sort like this ("ch" was considered an independent letter, and sorted
between c and d).
while 'ch' and 'll' are independent letters they sort as they were 'c'
and 'l'... that means that 'ch' should go before 'ck'
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Jaime Casanova wrote:
On Mon, Dec 15, 2008 at 10:26 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
It was sane behavior a couple of decades ago -- dictionaries used to
sort like this ("ch" was considered an independent letter, and sorted
between c and d).while 'ch' and 'll' are independent letters they sort as they were 'c'
and 'l'... that means that 'ch' should go before 'ck'
Interesting. So they are both wrong, glibc and teachers. We can file a
bug with glibc but I'm not sure we can do a lot about the other "bug".
Thanks for the research.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
Jaime Casanova wrote:
while 'ch' and 'll' are independent letters they sort as they were 'c'
and 'l'... that means that 'ch' should go before 'ck'
Interesting. So they are both wrong, glibc and teachers. We can file a
bug with glibc but I'm not sure we can do a lot about the other "bug".
Thanks for the research.
But I don't see this sorting behavior with glibc on Linux (Fedora 9 to
be exact, testing LC_COLLATE=es_ES.utf8). Does the mingw build actually
use glibc's strcoll() code, or is it somehow depending on Windows system
functionality?
I'm also wondering if the behavior is somehow affected by encoding ...
regards, tom lane
I wrote:
But I don't see this sorting behavior with glibc on Linux (Fedora 9 to
be exact, testing LC_COLLATE=es_ES.utf8).
BTW, I *do* see wieck < wiech in es_ES locale on HPUX 10.20, released
~1996. So I think we have correctly identified the core issue, and the
only interesting question is why mingw isn't following a more up-to-date
sorting rule.
Is it worth installing a variant rules regression output file for this?
I'd rather not, since that file tends to change often.
regards, tom lane
On Mon, Dec 15, 2008 at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Well, one thing you should try is
select 'wieck'::text < 'wiech'::text;
select 'wieck'::text > 'wiech'::text;
Administrador@casanova10 ~/pg.build/8.4dev
$ bin/psql -a -f test.sql postgres
select 'wieck'::text < 'wiech'::text;
?column?
----------
t
(1 row)
select 'wiech'::text < 'wieck'::text;
?column?
----------
f
(1 row)
just to confirm whether the comparisons are actually working that way
or we've got some other issue.
ok, confirmed...
You could also try initdb'ing in other
locales to see if the behavior changes.
Actually, using Spanish_Ecuador.1252 (wich is the one a i should use
from the beginning anyway ;) gives correct results, maybe the other
behaviour is correct in spain... we have a lot of spanish languages ;)
Administrador@casanova10 ~/pg.build/8.4dev
$ bin/psql -a -f test.sql postgres
select 'wieck'::text < 'wiech'::text;
?column?
----------
f
(1 row)
select 'wiech'::text < 'wieck'::text;
?column?
----------
t
(1 row)
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
On Mon, Dec 15, 2008 at 11:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
But I don't see this sorting behavior with glibc on Linux (Fedora 9 to
be exact, testing LC_COLLATE=es_ES.utf8).
doh! i'm seeing this again in HEAD (and in 8.3.5) when executing make
installcheck on openSuse 11
when initdb'ing i get this, that i think is right 'cause i was using
--locale=es_EC.UTF8:
The database cluster will be initialized with locale es_EC.UTF8.
The default database encoding has accordingly been set to UTF8.
The default text search configuration will be set to "spanish".
then i can confirm that in psql:
postgres=# show LC_COLLATE;
lc_collate
------------
es_EC.UTF8
(1 row)
nevertheless i get (and of course failed regression tests):
postgres=# select 'wieck'::text < 'wiech'::text;
?column?
----------
t
(1 row)
postgres=# select 'wieck'::text > 'wiech'::text;
?column?
----------
f
(1 row)
even worse, seems like the ordering is case insensitive in both 8.3.5
and HEAD, is this intended?
regression=# select 'S1' union all select 's1'
regression-# union all
regression-# select 'S2' union all select 's2'
regression-# order by 1;
?column?
----------
s1
S1
s2
S2
(4 rows)
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Attachments:
regression.diffsapplication/octet-stream; name=regression.diffsDownload
*** /home/postgres/pgsql/src/test/regress/expected/rules.out Sun Dec 21 16:13:13 2008
--- /home/postgres/pgsql/src/test/regress/results/rules.out Sun Dec 21 18:40:41 2008
***************
*** 414,422 ****
----------------------+--------------+------------+------------+------------
gates | t | fired | $0.00 | $80,000.00
gates | t | hired | $80,000.00 | $0.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(5 rows)
insert into rtest_empmass values ('meyer', '4000.00');
--- 414,422 ----
----------------------+--------------+------------+------------+------------
gates | t | fired | $0.00 | $80,000.00
gates | t | hired | $80,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(5 rows)
insert into rtest_empmass values ('meyer', '4000.00');
***************
*** 431,439 ****
maier | t | hired | $5,000.00 | $0.00
mayr | t | hired | $6,000.00 | $0.00
meyer | t | hired | $4,000.00 | $0.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(8 rows)
update rtest_empmass set salary = salary + '1000.00';
--- 431,439 ----
maier | t | hired | $5,000.00 | $0.00
mayr | t | hired | $6,000.00 | $0.00
meyer | t | hired | $4,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(8 rows)
update rtest_empmass set salary = salary + '1000.00';
***************
*** 449,457 ****
mayr | t | honored | $7,000.00 | $6,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(11 rows)
delete from rtest_emp using rtest_empmass where rtest_emp.ename = rtest_empmass.ename;
--- 449,457 ----
mayr | t | honored | $7,000.00 | $6,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(11 rows)
delete from rtest_emp using rtest_empmass where rtest_emp.ename = rtest_empmass.ename;
***************
*** 469,477 ****
meyer | t | fired | $0.00 | $5,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
- wiech | t | hired | $5,000.00 | $0.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
(14 rows)
--
--- 469,477 ----
meyer | t | fired | $0.00 | $5,000.00
meyer | t | hired | $4,000.00 | $0.00
meyer | t | honored | $5,000.00 | $4,000.00
wieck | t | honored | $6,000.00 | $5,000.00
wieck | t | honored | $7,000.00 | $6,000.00
+ wiech | t | hired | $5,000.00 | $0.00
(14 rows)
--
======================================================================
*** /home/postgres/pgsql/src/test/regress/expected/foreign_data.out Fri Dec 19 11:25:19 2008
--- /home/postgres/pgsql/src/test/regress/results/foreign_data.out Sun Dec 21 18:41:18 2008
***************
*** 658,667 ****
SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2;
foreign_server_catalog | foreign_server_name | foreign_data_wrapper_catalog | foreign_data_wrapper_name | foreign_server_type | foreign_server_version | authorization_identifier
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+--------------------------
- regression | S6 | regression | foo | | | foreign_data_user
regression | s4 | regression | foo | oracle | | foreign_data_user
regression | s5 | regression | foo | | 15.0 | regress_test_role
regression | s6 | regression | foo | | 16.0 | regress_test_indirect
regression | s8 | regression | postgresql | | | foreign_data_user
regression | st1 | regression | foo | | | regress_test_indirect
regression | st2 | regression | foo | | | regress_test_role
--- 658,667 ----
SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2;
foreign_server_catalog | foreign_server_name | foreign_data_wrapper_catalog | foreign_data_wrapper_name | foreign_server_type | foreign_server_version | authorization_identifier
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+--------------------------
regression | s4 | regression | foo | oracle | | foreign_data_user
regression | s5 | regression | foo | | 15.0 | regress_test_role
regression | s6 | regression | foo | | 16.0 | regress_test_indirect
+ regression | S6 | regression | foo | | | foreign_data_user
regression | s8 | regression | postgresql | | | foreign_data_user
regression | st1 | regression | foo | | | regress_test_indirect
regression | st2 | regression | foo | | | regress_test_role
***************
*** 670,680 ****
SELECT * FROM information_schema.foreign_server_options ORDER BY 1, 2, 3;
foreign_server_catalog | foreign_server_name | option_name | option_value
------------------------+---------------------+------------------+--------------
- regression | S6 | mixed_case_names | true
regression | s4 | dbname | b
regression | s4 | host | a
regression | s6 | dbname | b
regression | s6 | host | a
regression | s8 | connect_timeout | 30
regression | s8 | dbname | db1
(7 rows)
--- 670,680 ----
SELECT * FROM information_schema.foreign_server_options ORDER BY 1, 2, 3;
foreign_server_catalog | foreign_server_name | option_name | option_value
------------------------+---------------------+------------------+--------------
regression | s4 | dbname | b
regression | s4 | host | a
regression | s6 | dbname | b
regression | s6 | host | a
+ regression | S6 | mixed_case_names | true
regression | s8 | connect_timeout | 30
regression | s8 | dbname | db1
(7 rows)
***************
*** 682,693 ****
SELECT * FROM information_schema.user_mappings ORDER BY 1, 2, 3;
authorization_identifier | foreign_server_catalog | foreign_server_name
--------------------------+------------------------+---------------------
PUBLIC | regression | s4
PUBLIC | regression | s8
PUBLIC | regression | st1
- foreign_data_user | regression | S6
- foreign_data_user | regression | s4
- foreign_data_user | regression | s8
regress_test_role | regression | s5
regress_test_role | regression | s6
regress_test_role | regression | st1
--- 682,693 ----
SELECT * FROM information_schema.user_mappings ORDER BY 1, 2, 3;
authorization_identifier | foreign_server_catalog | foreign_server_name
--------------------------+------------------------+---------------------
+ foreign_data_user | regression | s4
+ foreign_data_user | regression | S6
+ foreign_data_user | regression | s8
PUBLIC | regression | s4
PUBLIC | regression | s8
PUBLIC | regression | st1
regress_test_role | regression | s5
regress_test_role | regression | s6
regress_test_role | regression | st1
***************
*** 696,705 ****
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+-----------------
- PUBLIC | regression | s4 | mapping | is public
- PUBLIC | regression | st1 | modified | 1
foreign_data_user | regression | S6 | username | test_mixed_case
foreign_data_user | regression | s8 | password | public
regress_test_role | regression | s5 | modified | 1
regress_test_role | regression | s6 | username | test
regress_test_role | regression | st1 | password | boo
--- 696,705 ----
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+-----------------
foreign_data_user | regression | S6 | username | test_mixed_case
foreign_data_user | regression | s8 | password | public
+ PUBLIC | regression | s4 | mapping | is public
+ PUBLIC | regression | st1 | modified | 1
regress_test_role | regression | s5 | modified | 1
regress_test_role | regression | s6 | username | test
regress_test_role | regression | st1 | password | boo
======================================================================