From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | peter_e(at)gmx(dot)net |
Cc: | lockhart(at)alumni(dot)caltech(dot)edu, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal for fixing numeric type-resolution issues |
Date: | 2000-05-18 00:09:54 |
Message-ID: | 20000518090954Y.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Thomas Lockhart writes:
>
> > Another 7.1 project is to work on alternate languages and character
> > sets, to decouple multibyte and locale from the default SQL_TEXT
> > character set. This will probably bring up issues similar to the
> > numeric problems, and since these character sets will be added as
> > user-defined types it will be important for the backend to understand
> > how to convert them for comparison operations, for example.
>
> Really? I always thought the character set would be some separate entity
> and perhaps an oid reference would be stored with every character string
> and attribute. That would get you around any type conversion as long as
> the functions acting on character types take this "header" field into
> account.
I think that way too. If what Thomas is suggesting is that to make a
user-defined charaset, one need to make everything such as operators,
charset, functions to work with index etc. (like defining new a data
type), that would be too painfull.
> If you want to go the data type way then you'd need to have some sort of
> most general character set to cast to. That could be Unicode but that
> would require that every user-defined character set be a subset of
> Unicode, which is perhaps not a good assumption to make.
Right. But the problem is SQL92 actually requires such a charset
called "SQL_TEXT." For me, the only candidate for SQL_TEX at this
point seems to be "mule internal code." Basically it is a variant of
ISO-2022 and has a capability to adapt to most of charsets defined in
ISO-2022. I think we could expand it so that it could become a
superset even for Unicode. Of course the problem is mule internal code
is a "internal code" and is not widely spread in the world. Even
that's true we could use it for purely internal purpose (for the parse
tree etc.).
> Also, I wonder
> how collations would fit in there. Collations definitely can't be ordered
> at all, so casting can't be done in a controlled fashion.
Hmm... Collations seem to be a different issue. I think there's no
such an idea like "collation casting" in SQL92.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-18 00:19:36 | Re: table level locking different in 7.0? |
Previous Message | Tom Lane | 2000-05-18 00:04:22 | Re: initdb and "exit_nicely"... |