Kevin Grittner <kgrittn@ymail.com> wrote:=0A=0A> Whether it is a bug in Win=
dows or in PostgreSQL character-=0A> handling under Windows I can say mysel=
f, since I haven't=0A> had any reason to use Windows for years.=0A=0AEr, th=
at should have been I *can't* say.=0A=0A>> create or replace function =CE=
=B1(=CE=B2 int, =CE=BE int, =CE=BC float) returns=0Afloat as $$=0A>> select=
(=CE=B2 + =CE=BE) * =CE=BC $$ language sql;=0A>> select =CE=B1(1, 2, 0.1);=
=0A>> -- it works=0A>> select ascii(proname), * from pg_proc where length(p=
roname) =3D 1;=0A>> -- return code 60536 although select ascii('=CE=B1') re=
truns 945=0A>> select * from pg_proc where proname =3D '=CE=B1';=0A>> -- re=
turns nothing=0A=0AIt occurs to me that the behavior you are seeing would b=
e=0Aconsistent with 945 being considered an uppercase letter, with=0A60536 =
being considered its lowercase form.=C2=A0 Normal PostgreSQL=0Acase-folding=
of identifiers would then cause exactly the symptoms=0Ayou are seeing.=C2=
=A0 You could test this theory by quoting its use as=0Aan identifier:=0A=0A=
create or replace function "=CE=B1"(=CE=B2 int, =CE=BE int, =CE=BC float) r=
eturns float=0Aas $$=0A=C2=A0 select (=CE=B2 + =CE=BE) * =CE=BC $$ language=
sql;=0Aselect "=CE=B1"(1, 2, 0.1);=0Aselect ascii(proname), * from pg_proc=
where length(proname) =3D 1;=0Aselect * from pg_proc where proname =3D '=
=CE=B1';=0A=0AIf that behaves correctly, you need to sort out what about yo=
ur=0Aenvironment is causing the odd case-folding.=0A=0A--=0AKevin Grittner=
=0AEDB: http://www.enterprisedb.com=0AThe Enterprise PostgreSQL Company