Further to my earlier e-mail, there would have to be two lines added to
conversion_create.sql for each alternate function name
Like:
CREATE OR REPLACE FUNCTION ascii_to_whatever (INTEGER, INTEGER, CSTRING,
CSTRING, INTEGER) RETURNS VOID AS '$libdir/ascmic', 'ascii_to_mic'
LANGUAGE 'c' STRICT;
CREATE CONVERSION pg_catalog.ascii_to_whatever FOR 'SQL_ASCII' TO
'MULE_INTERNAL' FROM ascii_to_whatever;
Lorne
In <200502262050.j1QKoNi10358@candle.pha.pa.us>, on 02/26/05
at 03:50 PM, Bruce Momjian <pgman@candle.pha.pa.us> said:
>Peter Eisentraut wrote:
>> Am Freitag, 25. Februar 2005 05:51 schrieb Bruce Momjian:
>> > so I see what he is saying. We are not consistent in favoring the
>> > official names vs. the common names.
>> >
>> > I will work on a patch that people can review and test.
>>
>> I think this is what we should do:
>>
>> UNICODE => UTF8
>> ALT => WIN866
>> WIN => WIN1251
>> TCVN => WIN1258
>>
>> That should clear it up.
>OK, here is a patch that makes those changes.
>The only uncertainty I have is with the the use of the TCVN conversion
>routine names, e.g.:
> SELECT CONVERT('foo' USING tcvn_to_utf_8);
>I assume this is the same as:
> SELECT CONVERT('foo', 'WIN1258', 'UTF8');
>and
> SELECT CONVERT('foo', 'TCVN', 'UTF8'); -- alias usage
>So, why would people use the routine name? Both forms are documented.
>The first one with USING does not accept aliases, while the others do.
>I think this should be renamed to win1258_to_utf_8. However, this would
>be an incompatibility. We should mention it in the release notes.
>Other than that the other conversion files were already named fine, e.g.
>ascii_to_utf_8 (no UNICODE), however it is utf_8 and not utf8. I am
>unsure how to handle these.
--
-----------------------------------------------------------
lsunley@mb.sympatico.ca
-----------------------------------------------------------