On Thu, Jul 11, 2002 at 03:37:49PM +0900, Tatsuo Ishii wrote:
> > > 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:
OK.
> pgconv(
> INTEGER, -- source encoding id
> INTEGER, -- destination encoding id
Where/how is describe conversion between encoding id and encoding
name? (I maybe something overlook:-) I expect new encoding system
will extendable and encodings list not will hardcoded like now.
(extendable = add new encoding without PostgreSQL rebuild)
BTW, the client site needs routines for work with encoding names too
(pg_char_to_encoding()). Hmm.. it can't be extendable, or yes?
> OPAQUE, -- source string (null terminated C string)
> OPAQUE, -- destination string (null terminated C string)
> INTERGER -- source string length
> ) returns INTEGER; -- dummy. returns nothing, actually.
Karel
--
Karel Zak <[EMAIL PROTECTED]>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
