> > If it does work, then it's ok. However still I'm not sure why current
> > method is evil.
>
> Because with the current definition, any change in search_path really
> ought to lead to repeating the lookup for the default conversion proc.
> That's a bad idea from a performance point of view and I don't think
> it's a particularly good idea from the definitional point of view
> either --- do you really want the client conversion changing because
> some function altered the search path?
That argument does not strike me too strongly. I cannot imagine the
case search_path changed so frequently.
> AFAICT we invented the entire concept of conversions ourselves. I see
> nothing about CREATE CONVERSION in the SQL spec. There is a CREATE
> TRANSLATION in SQL2003, which we'd probably not seen when we invented
> CREATE CONVERSION, but it does *not* have a DEFAULT clause. I don't
> think you can point to the spec to defend our current method of
> selecting which conversion to use.
SQL's CONVERT and TRANSLATE are different things. CONVERT changes
encodings, while TRANSLATE changes character sets. However sometimes
the difference between encodings and character sets are vague,
for some encodings such as LATIN* and SJIS.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
