From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | zakkr(at)zf(dot)jcu(dot)cz |
Cc: | peter_e(at)gmx(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: CREATE CONVERSION |
Date: | 2002-07-11 06:37:49 |
Message-ID: | 20020711.153749.71182832.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > For example you want to define a function for LATIN1 to UNICODE conversion
> > function would look like:
> >
> > function_for_LATIN1_to_UTF-8(from_string opaque, to_string opaque, length
> > integer)
> > {
> > :
> > :
> > generic_function_using_iconv(from_str, to_str, "ISO-8859-1", "UTF-8",
> > length);
> > }
> >
> > CREATE FUNCTION function_for_LATIN1_to_UTF-8(opaque, opaque, integer)
> > RETURNS integer;
> > CREAE CONVERSION myconversion FOR 'LATIN1' TO 'UNICODE' FROM
> > function_for_LATIN1_to_UTF-8;
>
> Hmm, but it require define "function_for_..." for each conversion.
> For example trigger function I needn't define for each table, but I can
> use only one PostgreSQL function for arbirary table.
I don't think this is a big problem, IMO.
However, thinking more, I came to a conclusion that passing encoding
ids would be a good thing. With the encoding id parameters, the
function could check if it is called with correct encodings, and this
would prevent disaster. New interface proposal:
pgconv(
INTEGER, -- source encoding id
INTEGER, -- destination encoding id
OPAQUE, -- source string (null terminated C string)
OPAQUE, -- destination string (null terminated C string)
INTERGER -- source string length
) returns INTEGER; -- dummy. returns nothing, actually.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2002-07-11 07:57:12 | new SQL command: CREATE CONVERSION/DROP CONVERSION added |
Previous Message | Groff, Dana | 2002-07-11 04:59:48 | Re: Should this require CASCADE? |