> > 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
