Обсуждение: LIKE predicate and ERROR: 42P22: could not determine which collation to use for string comparison - HINT: Use the COLLATE clause ...
postgresql 9.1.2 running on linux debian squeeze on 32-bit x86
I have encountered behaviour relating to subject line which I'm fairly sure=
is a bug,=A0 although I'm not sure exactly what.
My database was created with LC_LOCALE C,=A0=A0 and loaded using Pg-9.1.1. =
=A0 it looks like
psql -d proteusdb -c "select datname, datdba, encoding, datcollate, datctyp=
e, datistemplate, datallowconn, datconnlimit, datlastsysoid, datfrozenxid, =
dattablespace from pg_database where datname =3D 'proteusdb'";
=A0 datname=A0 | datdba | encoding | datcollate | datctype | datistemplate =
| datallowconn | datconnlimit | datlastsysoid | datfrozenxid | dattablespac=
e=20
-----------+--------+----------+------------+----------+---------------+---=
-----------+--------------+---------------+--------------+---------------
=A0proteusdb |=A0=A0=A0=A0 10 |=A0=A0=A0=A0=A0=A0=A0 6 | C=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 | C=A0=A0=A0=A0=A0=A0=A0 | f=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 | t=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -1=
|=A0=A0=A0=A0=A0=A0=A0=A0 11910 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 670 |=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 1663
(1 row)
=A0I have a table which as a column named discriminator :
CREATE TABLE entity (
=A0=A0=A0 id bigint DEFAULT nextval('entity_id_seq'::regclass) NOT NULL,
=A0=A0=A0 discriminator character varying(255) NOT NULL,
=A0=A0=A0 version integer NOT NULL,
=A0=A0=A0 inherit_right boolean,
=A0=A0=A0 name text,
=A0=A0=A0 parent_id bigint,
=A0=A0=A0 association_id bigint,
=A0=A0=A0 association2_id bigint,
=A0=A0=A0 long1 bigint,
=A0=A0=A0 long2 bigint
);
which shows up looking like this in the catalog
psql -d proteusdb -c "select N.nspname , C.relname, A.attrelid , A.attname =
, A.atttypid , T.typname , L.collname from pg_attribute A, pg_type T, pg_cl=
ass C , pg_namespace N , pg_collation L where C.oid =3D A.attrelid and T.oi=
d =3D A.atttypid and A.attcollation =3D L.oid and C.relnamespace =3D N.oid =
and N.nspname =3D 'public' and C.relname =3D 'entity' and A.attname =3D 'di=
scriminator'";
=A0nspname | relname | attrelid |=A0=A0=A0 attname=A0=A0=A0 | atttypid | ty=
pname | collname=20
---------+---------+----------+---------------+----------+---------+-------=
---
=A0 public=A0 | entity=A0 |=A0=A0=A0 25349 | discriminator |=A0=A0=A0=A0 10=
43 | varchar | default
(1 row)
and a query like so :
psql -d proteusdb -c "select count(*) from entity=A0 as e1 where ( e1.assoc=
iation_id IN ( select id from entity as e2 where e2.parent_id=3D3043508)=A0=
=A0 OR e1.association_id=3D3043508 ) and e1.discriminator LIKE 'DEPLOY%'";
ERROR:=A0 could not determine which collation to use for string comparison
HINT:=A0 Use the COLLATE clause to set the collation explicitly.
explain gives a clue what is going on :
psql -d proteusdb -c "explain select count(*) from entity=A0 as e1 where ( =
e1.association_id IN ( select id from entity as e2 where e2.parent_id=3D304=
3508)=A0=A0 OR e1.association_id=3D3043508 ) and e1.discriminator LIKE 'DEP=
LOY%'";
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 QUERY PLAN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
---------------------------------------------------------------------------=
------------------------------------------
=A0Aggregate=A0 (cost=3D85045.70..85045.71 rows=3D1 width=3D0)
=A0=A0 ->=A0 Index Scan using entity_id_association_id_discriminator on ent=
ity e1=A0 (cost=3D523.55..85045.61 rows=3D36 width=3D0)
=A0=A0=A0=A0=A0=A0=A0=A0 Index Cond: (((discriminator)::text >=3D 'DEPLOY':=
:text) AND ((discriminator)::text < 'DEPLOZ'::text))
=A0=A0=A0=A0=A0=A0=A0=A0 Filter: (((discriminator)::text ~~ 'DEPLOY%'::text=
) AND ((hashed SubPlan 1) OR (association_id =3D 3043508)))
=A0=A0=A0=A0=A0=A0=A0=A0 SubPlan 1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ->=A0 Index Scan using entity_parent_id on e=
ntity e2=A0 (cost=3D0.00..522.84 rows=3D281 width=3D8)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Index Cond: (parent_id =3D=
3043508)
(7 rows)
So Pg has rewritten my LIKE pred to add the pair of range predicates so as =
to be able to exploit my index ... Good.
However=A0 ---=A0=A0 It has then discovered that there is a mismatch betwee=
n the collation of the column (default) and the constant (I assume C,=A0 in=
herited from the database).
Well=A0=A0 --=A0=A0=A0 I am not an expert on collation,=A0=A0 but I am fair=
ly sure that the semantics of the LIKE predicate do not involve order,=A0=
=A0 so an error relating to ordering or collation should be impossible.=A0=
=A0=A0=A0 LIKE involves only exact (equality) matching of parts of the colu=
mn value against the pattern.=A0=A0=A0=A0 If the query rewriter has satisif=
ied itself that it is a correct transformation of the query to add the two =
range predicates,=A0=A0 then it must=A0 (should?)=A0 have checked that any =
mismatch of collation does not affect correctness, and therefore no other p=
art of postgres (planner,=A0 runtime) should then object on those grounds.
So=A0 - I *think* there is a=A0 bug,=A0=A0 either that the query should not=
have been rewritten=A0 (if collation does indeed make the rewrite incorrec=
t),=A0 or else it should have planned and executed the rewritten query.
I re-ran this on PG 9.1.2 to check and the same happens there as well.
Hoping that some expert can make a ruling on this.
John Lumby
=20=09=09=20=09=20=20=20=09=09=20=20
John Lumby <johnlumby@hotmail.com> writes:
> psql -d proteusdb -c "select count(*) from entity as e1 where ( e1.association_id IN ( select id from entity as e2
wheree2.parent_id=3043508) OR e1.association_id=3043508 ) and e1.discriminator LIKE 'DEPLOY%'";
> ERROR: could not determine which collation to use for string comparison
> HINT: Use the COLLATE clause to set the collation explicitly.
FWIW, I tried to replicate this on the basis of the limited information
you gave, and could not. Can you provide a self-contained test case?
regards, tom lane
Sorry about that,=A0=A0 here is a script to demonstrate using a much simple=
r example.
It presumes linux and that there is a bash shell at /bin/bash.
You should see table created and loaded (takes a few minutes),=A0=A0 then s=
uccessful query explain and run,
then create index and re-run the explain (now uses index) and query (now fa=
ils)
John
############################################### snip
#!/bin/bash
#=A0=A0 demonstrate bug :=20
#=A0=A0 LIKE predicate and ERROR:=A0 42P22: could not determine which colla=
tion to use for string comparison -
#=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 HINT:=A0 Use the COLLATE clause ...132
#=A0=A0 WARNING=A0=A0 this script will (try to) drop and recreate a databas=
e named LIKE_42P22
echo "WARNING=A0=A0 this script will (try to) drop and recreate a database =
named LIKE_42P22
press enter to continue or Ctl-C to cancel"
read nothing
export LANG=3D"C"
export LC_ALL=3D"C"
export LC_LOCALE=3D"C"
psql -d postgres -c "DROP DATABASE IF EXISTS \"LIKE_42P22\"";
LANG=3D"C" LC_LOCALE=3D"C" createdb -T template0 -E UTF8 LIKE_42P22;
psql -d LIKE_42P22 -c "CREATE TABLE entity ( id bigint NOT NULL, discrimina=
tor character varying(255) NOT NULL )";
date;declare -i rc=3D0 id=3D1 count=3D0 index remdr;
declare -a ALPHABET=3D(A B C D E F G H I J K L M N O P Q R S T U V W X Y Z);
while [[ $rc -eq 0 ]] && [[ $id -le 10000 ]]; do {
=A0=A0=A0=A0 ((index=3Did/500)); ((remdr=3Did%20));discriminator=3D"${ALPHA=
BET[$index]}EPLOY${remdr}padding";
=A0=A0=A0=A0 psql -d LIKE_42P22 -c "INSERT INTO entity values ( $id , '${di=
scriminator}' )" >/dev/null;rc=3D$?;
=A0=A0=A0=A0 [[ $rc -eq 0 ]] && ((count=3Dcount+1)); ((id=3Did+1));
}; done; echo "rc=3D $rc inserted $count entities $(date)";
psql -d LIKE_42P22 -c "ANALYZE entity";
#=A0=A0 display catalog metadata
psql -d LIKE_42P22 -c "select datname, datdba, encoding, datcollate, datcty=
pe, datistemplate, datallowconn, datconnlimit, datlastsysoid, datfrozenxid,=
dattablespace from pg_database where datname =3D 'LIKE_42P22'";
psql -d LIKE_42P22 -c "select N.nspname , C.relname, A.attrelid , A.attname=
, A.atttypid , T.typname , L.collname from pg_attribute A, pg_type T, pg_c=
lass C , pg_namespace N , pg_collation L where C.oid =3D A.attrelid and T.o=
id =3D A.atttypid and A.attcollation =3D L.oid and C.relnamespace =3D N.oid=
and N.nspname =3D 'public' and C.relname =3D 'entity' and A.attname =3D 'd=
iscriminator'";
#=A0 run the problem query before any index on discriminator=A0 -=A0 it sho=
uld work
psql -d LIKE_42P22 -c "EXPLAIN select count(*) from entity as e1 where e1.d=
iscriminator LIKE 'DEPLOY%'";
psql -d LIKE_42P22 -c "select Count(*) from entity as e1 where e1.discrimin=
ator like 'DEPLOY%'"; # should be 500 matches
#=A0=A0 now create index and the bug will strike
psql -d LIKE_42P22 -c "CREATE INDEX entity_discriminator ON entity USING bt=
ree (discriminator)";
psql -d LIKE_42P22 -c "ANALYZE entity";
psql -d LIKE_42P22 -c "EXPLAIN select count(*) from entity as e1 where e1.d=
iscriminator LIKE 'DEPLOY%'";
psql -d LIKE_42P22 -c "select count(*) from entity as e1 where e1.discrimin=
ator LIKE 'DEPLOY%'";=A0 #=A0 should fail
############################################### snip
----------------------------------------
> To: johnlumby@hotmail.com
> CC: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] LIKE predicate and ERROR: 42P22: could not determine =
which collation to use for string comparison - HINT: Use the COLLATE clause=
...
> Date: Sat, 10 Dec 2011 03:26:13 -0500
> From: tgl@sss.pgh.pa.us
>
> John Lumby <johnlumby@hotmail.com> writes:
> > psql -d proteusdb -c "select count(*) from entity as e1 where ( e1.ass=
ociation_id IN ( select id from entity as e2 where e2.parent_id=3D3043508) =
OR e1.association_id=3D3043508 ) and e1.discriminator LIKE 'DEPLOY%'";
> > ERROR: could not determine which collation to use for string comparison
> > HINT: Use the COLLATE clause to set the collation explicitly.
>
> FWIW, I tried to replicate this on the basis of the limited information
> you gave, and could not. Can you provide a self-contained test case?
>
> regards, tom lane
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
=20=09=09=20=09=20=20=20=09=09=20=20
John Lumby <johnlumby@hotmail.com> writes:
> Sorry about that, here is a script to demonstrate using a much simpler example.
> It presumes linux and that there is a bash shell at /bin/bash.
> You should see table created and loaded (takes a few minutes), then successful query explain and run,
> then create index and re-run the explain (now uses index) and query (now fails)
Hmm ... I tried this script on both HEAD and 9.1, and see no failure.
Possibly it requires some non-default configuration setting to show
the problem? Also, are you certain your database is ending up with
LC_COLLATE and LC_CTYPE set to "C"? I am not sure that createdb pays
attention to those as locale settings.
regards, tom lane
Well,=A0 thanks for trying it=A0 -=A0 but that is strange.=A0=A0 Yes,=A0 my= database is created with datcollate "C"=A0 - the script displays that (see below). The only thing I can think of that might explain different outcome is if,= =A0 in your environment, the planner did not choose the index-access plan after the index was create= d, and/or did not add the two range predicates.=A0=A0=A0 Is that the case? The script output shows the two plans before and after creating the index. Here is the output from running the script just now=20 (and I ran it on a very different system than before just to get another sample point and it exhibits the same bug). Is your output different?=A0=A0 Do you think you could post the output you = get? Regards,=A0=A0=A0 John Lumby ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------- /home/postgres/bin/demo_like_42p22.sh WARNING=A0=A0 this script will (try to) drop and recreate a database named = LIKE_42P22 press enter to continue or Ctl-C to cancel NOTICE:=A0 database "LIKE_42P22" does not exist, skipping DROP DATABASE CREATE TABLE Tue Dec 13 08:50:12 EST 2011 rc=3D 0 inserted 10000 entities Tue Dec 13 09:05:30 EST 2011 ANALYZE =A0 datname=A0=A0 | datdba | encoding | datcollate | datctype | datistempla= te | datallowconn | datconnlimit | datlastsysoid | datfrozenxid | dattables= pace=20 ------------+--------+----------+------------+----------+---------------+--= ------------+--------------+---------------+--------------+--------------- =A0LIKE_42P22 |=A0=A0=A0=A0 10 |=A0=A0=A0=A0=A0=A0=A0 6 | C=A0=A0=A0=A0=A0= =A0=A0=A0=A0 | C=A0=A0=A0=A0=A0=A0=A0 | f=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 | t=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -1= |=A0=A0=A0=A0=A0=A0=A0=A0 11910 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 670 |=A0=A0= =A0=A0=A0=A0=A0=A0=A0 1663 (1 row) =A0nspname | relname | attrelid |=A0=A0=A0 attname=A0=A0=A0 | atttypid | ty= pname | collname=20 ---------+---------+----------+---------------+----------+---------+-------= --- =A0public=A0 | entity=A0 |=A0=A0=A0 26506 | discriminator |=A0=A0=A0=A0 104= 3 | varchar | default (1 row) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 QUERY PLAN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=20 ------------------------------------------------------------------- =A0Aggregate=A0 (cost=3D190.26..190.27 rows=3D1 width=3D0) =A0=A0 ->=A0 Seq Scan on entity e1=A0 (cost=3D0.00..189.00 rows=3D505 width= =3D0) =A0=A0=A0=A0=A0=A0=A0=A0 Filter: ((discriminator)::text ~~ 'DEPLOY%'::text) (3 rows) =A0count=20 ------- =A0=A0 500 (1 row) CREATE INDEX ANALYZE =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 QU= ERY PLAN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=20 ---------------------------------------------------------------------------= ----------------------------------- =A0Aggregate=A0 (cost=3D23.71..23.72 rows=3D1 width=3D0) =A0=A0 ->=A0 Index Scan using entity_discriminator on entity e1=A0 (cost=3D= 0.00..22.45 rows=3D505 width=3D0) =A0=A0=A0=A0=A0=A0=A0=A0 Index Cond: (((discriminator)::text >=3D 'DEPLOY':= :text) AND ((discriminator)::text < 'DEPLOZ'::text)) =A0=A0=A0=A0=A0=A0=A0=A0 Filter: ((discriminator)::text ~~ 'DEPLOY%'::text) (4 rows) ERROR:=A0 could not determine which collation to use for string comparison HINT:=A0 Use the COLLATE clause to set the collation explicitly. ---------------------------------------- > To: johnlumby@hotmail.com > CC: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] LIKE predicate and ERROR: 42P22: could not determine = which collation to use for string comparison - HINT: Use the COLLATE clause= ... > Date: Mon, 12 Dec 2011 16:38:53 -0500 > From: tgl@sss.pgh.pa.us > > John Lumby <johnlumby@hotmail.com> writes: > > Sorry about that, here is a script to demonstrate using a much simple= r example. > > It presumes linux and that there is a bash shell at /bin/bash. > > > You should see table created and loaded (takes a few minutes), then s= uccessful query explain and run, > > then create index and re-run the explain (now uses index) and query (no= w fails) > > Hmm ... I tried this script on both HEAD and 9.1, and see no failure. > Possibly it requires some non-default configuration setting to show > the problem? Also, are you certain your database is ending up with > LC_COLLATE and LC_CTYPE set to "C"? I am not sure that createdb pays > attention to those as locale settings. > > regards, tom lane > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs =20=09=09=20=09=20=20=20=09=09=20=20
John Lumby <johnlumby@hotmail.com> writes:
> Is your output different? Do you think you could post the output you get?
Mine looks like yours, except no error. [ looks closer... ] Are you
sure you're running a 9.1.2 server? The large difference in
datlastsysoid seems like it could not have happened if you had
production 9.1.x system catalog contents. Now I'm suspicious there's
something wrong with your catalog entries, not the code itself.
DROP DATABASE
CREATE TABLE
Tue Dec 13 09:59:18 EST 2011
rc= 0 inserted 10000 entities Tue Dec 13 10:00:30 EST 2011
ANALYZE
datname | datdba | encoding | datcollate | datctype | datistemplate | datallowconn | datconnlimit | datlastsysoid |
datfrozenxid| dattablespace
------------+--------+----------+------------+----------+---------------+--------------+--------------+---------------+--------------+---------------
LIKE_42P22 | 10 | 6 | C | C | f | t | -1 | 12772 |
1795 | 1663
(1 row)
nspname | relname | attrelid | attname | atttypid | typname | collname
---------+---------+----------+---------------+----------+---------+----------
public | entity | 41366 | discriminator | 1043 | varchar | default
(1 row)
QUERY PLAN
-------------------------------------------------------------------
Aggregate (cost=190.26..190.27 rows=1 width=0)
-> Seq Scan on entity e1 (cost=0.00..189.00 rows=505 width=0)
Filter: ((discriminator)::text ~~ 'DEPLOY%'::text)
(3 rows)
count
-------
500
(1 row)
CREATE INDEX
ANALYZE
QUERY PLAN
--------------------------------------------------------------------------------------------------------------
Aggregate (cost=23.71..23.72 rows=1 width=0)
-> Index Scan using entity_discriminator on entity e1 (cost=0.00..22.45 rows=505 width=0)
Index Cond: (((discriminator)::text >= 'DEPLOY'::text) AND ((discriminator)::text < 'DEPLOZ'::text))
Filter: ((discriminator)::text ~~ 'DEPLOY%'::text)
(4 rows)
count
-------
500
(1 row)
regards, tom lane
Yes,=A0 I'm definitely running 9.1.2 (on the output I sent earlier today). I've also tried again on yet another different system and get the same bug = there. I do have other databases in my cluster which probably explains the differe= nt datlastsysoid. I am at a loss to explain what could be different.=A0 I've run it on differ= ent machines, different linux distros and both postgres 9.1 releases,=A0=A0 and see same = result every time. There must be some (other) external environmental factor.=A0=A0 Do you happ= en to know of any?=A0 I wonder if the locale in effect when I ran initdb affects it? I would have had LANG=3DC and LC_ALL=3DC exported.=A0=A0=A0=A0 Do you have any system where you could try an initdb with those environment vars export= ed? What are the values of relevant locale-type env vars when you ran initdb on= your test sys? Regards,=A0=A0=A0 John Lumby ---------------------------------------- =20=09=09=20=09=20=20=20=09=09=20=20
John Lumby <johnlumby@hotmail.com> writes:
> I do have other databases in my cluster which probably explains the different datlastsysoid.
No, it wouldn't. datlastsysoid only counts objects created during
initdb.
[ thinks for a bit ] The most likely explanation for the different
datlastsysoid value is that the number of pre-created pg_collation
entries is quite a bit different on my box than yours, as a result of a
different list from "locale -a". It's hard to see why that would have
anything to do with your issue, but I have a feeling it does somehow.
What platforms have you tried this on, exactly? I tried it on Fedora 14.
> What are the values of relevant locale-type env vars when you ran initdb on your test sys?
Shrug ... C. That's my normal working environment. I did try it with
en_US.utf8 too, just for grins.
regards, tom lane
(Horribly red face) All my fault.=A0=A0=A0 It turns out I had applied a source-code change for = some additional dtracing which I had merged forward from an older version b= ut which was incorrect in V9.=A0=A0=A0 After removing that it works fine. Really sorry about that .... John Lumby ---------------------------------------- > To: johnlumby@hotmail.com > CC: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] LIKE predicate and ERROR: 42P22: could not determine = which collation to use for string comparison - HINT: Use the COLLATE clause= ... > Date: Tue, 13 Dec 2011 14:04:02 -0500 > From: tgl@sss.pgh.pa.us > > John Lumby <johnlumby@hotmail.com> writes: > > I do have other databases in my cluster which probably explains the dif= ferent datlastsysoid. > > No, it wouldn't. datlastsysoid only counts objects created during > initdb. > > [ thinks for a bit ] The most likely explanation for the different > datlastsysoid value is that the number of pre-created pg_collation > entries is quite a bit different on my box than yours, as a result of a > different list from "locale -a". It's hard to see why that would have > anything to do with your issue, but I have a feeling it does somehow. > > What platforms have you tried this on, exactly? I tried it on Fedora 14. > > > What are the values of relevant locale-type env vars when you ran initd= b on your test sys? > > Shrug ... C. That's my normal working environment. I did try it with > en_US.utf8 too, just for grins. > > regards, tom lane > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs =20=09=09=20=09=20=20=20=09=09=20=20