Re: Charset/collate support and function parameters

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: db(at)zigo(dot)dhs(dot)org
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Charset/collate support and function parameters
Date: 2004-10-31 06:15:14
Message-ID: 20041031.151514.26271501.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > For me that seems to be the right way. I'm not sure if two oids are
> > the right solution but we need to store extra info in varlena
> > structure to support charset/collation anyway. In my understanding
> > TOAST has already done in similar way.
> >
> > Other than charset/collation we also need coercibility info to meet
> > with the SQL standard. This could only be represented in each text,
> > not by function parameters.
>
> Arn't we limiting ourself in how we can use charsets when we remove it
> from the type.

? That is a news to me. In my understanding nobody did remove charsets
from the type. The charset info has not been in text type since
PostgreSQL was born.

> The reason why I started to look at the function parameters
> is because in the standard one can do this:
>
> CREATE CHARACTER SET foo GET Latin1;

Surely we want add this to PostgreSQL.

> and now we could add functions that work with this charset
>
> CREATE FUNCTION bar (x VARCHAR(255) CHARACTER SET foo) ....
>
> What we are saying is that we don't want to be able to do this?

Not sure we want to add above. Is it something defined in the
standard?

Though I think we want to add something like:

SELECT bar(x CHARACTER SET foo COLLATE buz) ....

> I just
> want to understand all the implications of simplifying the types.
>
> Same thing if the user wants to create new collations using CREATE
> COLLATION. How can we override functions for these new charsets and
> collations if all we can define are functions like foo(x VARCHAR)?
>
> Maybe one wants the information in both place.

I think we could make our text type richer so that it could include
charset, collate info and so on.

At this point my plan to implement CREATE CHARSET/COLLATE includes:

1) add charset/collation info to pg_attribute
2) make shared tables such as pg_database and pg_shadow can handle
multiple charsets. this is necessary because database names and
user names could be repsented in different charsets
3) create new system catalogs to keep defined charsets and collations
4) make text type on memory representation richer so that it can keep
chaset/collate/coercibility etc. info
5) enhance pg_am and friends
6) create our own locale database
--
Tatsuo Ishii

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2004-10-31 06:16:46 Re: not null partial index?
Previous Message Tom Lane 2004-10-31 06:10:38 Re: not null partial index?