On Sat, 2002-11-30 at 01:40, Nicolai Tufar wrote:
And I happen to have bad luck to use PostgreSQL with Turkish locale. And, as
you
may know our I is not your I:
pgsql=# create table a(x char(1));
CREATE TABLE
pgsql=# grant SELECT ON a to PUBLIC;
ERROR: user public does
On Sat, 2002-11-30 at 07:57, Nicolai Tufar wrote:
With this, no matter what kind of I you used in names,
it is always going to end up a valid ASCII character.
Would it be acceptable if I submit a path that applies this
special logic in src/backend/parser/scan.l if the locale is tr_TR?
Nicolai Tufar [EMAIL PROTECTED] writes:
Historically programs that operate in Turkish locale have
chosen to hardcode the capitalisation of i in system
messages and identifier names like this:
Lower: I - i and Y' - i.
Upper: y' - I and i - I.
If that's the behavior you want, why don't you
- Original Message -
From: Hannu Krosing [EMAIL PROTECTED]
To: Nicolai Tufar [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, November 30, 2002 5:41 PM
Subject: Re: [HACKERS] Locale-dependent case conversion in {identifier}
[ ... ]
could it just be that we store
Nicolai Tufar [EMAIL PROTECTED] writes:
So I have changed lower-case conversion code in scan.l to make it purely
ASCII-based.
as in keywords.c. Mini-patch is given below.
Rather than offering a patch, you need to convince us why our reading of
the SQL standard is wrong. (Oracle does it that
By no means I would try to convince that your reading of
the SQL standards is wrong. What I am trying to tell is
that Turkish alphabet is broken beyond repair. And since
there is absolutely no way to change our alphabet, we
may can code a workaround in the code.
So i do not claim that your code