Re: Charset/collate support and function parameters

From: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
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 05:28:39
Message-ID: Pine.LNX.4.44.0410310551020.2015-100000@zigo.dhs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 31 Oct 2004, Tatsuo Ishii wrote:

> > So you want to expand every string with 8 bytes (two oid's)?
>
> 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. 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;

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

--
/Dennis Björklund

In response to

Responses

Browse pgsql-hackers by date

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