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-16 14:37:35 |
Message-ID: | 394A3BAF.25622EBE@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> "default database character set" idea does not seem to be the solution
> for cross-db relations such as pg_database. The only solution I can
> imagine so far is using SQL_TEXT.
> BTW, I've been thinking about SQL_TEXT for a while and it seems
> mule_internal_code or Unicode(UTF-8) would be the candidates for
> it. Mule_internal_code looks more acceptable for Asian multi-byte
> users like me than Unicode. It's clean, simple and does not require
> huge conversion tables between Unicode and other encodings. However,
> Unicode has a stronger political power in the real world and for most
> single-byte users probably it would be enough. My idea is let users
> choose one of them. I mean making it a compile time option.
Oh. I was recalling SQL_TEXT as being a "subset" character set which
contains only the characters (more or less) that are required for
implementing the SQL92 query language and standard features.
Are you seeing it as being a "superset" character set which can
represent all other character sets??
And, how would you suggest we start tracking this discussion in a design
document? I could put something into the developer's guide, or we could
have a plain-text FAQ, or ??
I'd propose that we start accumulating a feature list, perhaps ordering
it into categories like
o required/suggested by SQL9x
o required/suggested by experience in the real world
o sure would be nice to have
o really bad idea ;)
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-16 14:44:19 | Re: Changes to functions and triggers |
Previous Message | Tatsuo Ishii | 2000-06-16 14:03:57 | Re: Re: Big 7.1 open items |