Re: Proposal: CREATE CONVERSION

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 encodingname? (I maybe something overlook:-) I expect new
encodingsystem will extendable and encodings list not will hardcoded like now.(extendable = add new encoding without
PostgreSQLrebuild)
 
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  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz