Re: Re: Big 7.1 open items

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: robinson(at)netrinsics(dot)com, pgsql-hackers(at)hub(dot)org
Subject: Re: Re: Big 7.1 open items
Date: 2000-06-15 14:14:47
Message-ID: 3948E4D7.A3B722E9@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> o Don't accept character sequences those are not valid as their
> charset (signaling ERROR seems appropriate IMHO)
> o Make PostgreSQL more multibyte aware (for example, TRIM function and
> NAME data type)
> o Regard n of CHAR(n)/VARCHAR(n) as the number of letters, rather than
> the number of bytes

All good, and important features when we are done.

One issue: I can see (or imagine ;) how we can use the Postgres type
system to manage multiple character sets. But allowing arbitrary
character sets in, say, table names forces us to cope with allowing a
mix of character sets in a single column of a system table. afaik this
general capability is not mandated by SQL9x (the SQL_TEXT character set
is used for all system resources??). Would it be acceptable to have a
"default database character set" which is allowed to creep into the
pg_xxx tables? Even that seems to be a difficult thing to accomplish at
the moment (we'd need to get some of the text manipulation functions
from the catalogs, not from hardcoded references as we do now).

We should itemize all of these issues so we can keep track of what is
necessary, possible, and/or "easy".

- Thomas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-06-15 14:16:54 Re: [HACKERS] info on unixODBC/Postgres driver port to IRIX 6.5.7 64bit
Previous Message Mark Hollomon 2000-06-15 14:05:10 Bug with views and defaults