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-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

In response to

Responses

Browse pgsql-hackers by date

  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