Re: Charset/collate support and function parameters - Mailing list pgsql-hackers

From Dennis Bjorklund
Subject Re: Charset/collate support and function parameters
Date
Msg-id Pine.LNX.4.44.0410310551020.2015-100000@zigo.dhs.org
Whole thread Raw
In response to Re: Charset/collate support and function parameters  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: Charset/collate support and function parameters
List 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



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: not null partial index?
Next
From: Tom Lane
Date:
Subject: Re: not null partial index?