I have added new function called "convert" similar to SQL99's convert.
Convert converts encoding according to parameters. For example, if you
have a table named "unicode" in an Unicode database,
SELECT convert(text_field, 'LATIN1') FROM unicode;
will return text in ISO-8859-1 representation. Thi
> I have added new function called "convert" similar to SQL99's convert.
> Convert converts encoding according to parameters. For example, if you
> have a table named "unicode" in an Unicode database,
Forgot to mention that anyone who wants to try the new function should
do initdb. I did not incr
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I have added new function called "convert" similar to SQL99's convert.
> Convert converts encoding according to parameters. For example, if you
> have a table named "unicode" in an Unicode database,
> SELECT convert(text_field, 'LATIN1') FROM unicode;
>
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I have added new function called "convert" similar to SQL99's convert.
> > Convert converts encoding according to parameters. For example, if you
> > have a table named "unicode" in an Unicode database,
>
> > SELECT convert(text_field, 'LATIN1') FROM
I have just noticed that the implementation of
CONVERT(text USING encoding_name)
tries to do database access during the grammar phase, viz it looks
up the encoding_name in pg_conversion and replaces it with an OID.
This is not workable; consider the situation where we are in an
already-abo
On Sat, 2 Nov 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Unfortunately, I don't see any way offhand to fix this without an
> >> initdb :-(.
>
> > Ooch, that hurts. How bad would it be if it was broken in 7.3?
>
> We could dike out the feature:
>
> c
Tom Lane wrote:
> I have just noticed that the implementation of
> CONVERT(text USING encoding_name)
> tries to do database access during the grammar phase, viz it looks
> up the encoding_name in pg_conversion and replaces it with an OID.
>
> This is not workable; consider the situation wher
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Unfortunately, I don't see any way offhand to fix this without an
>> initdb :-(.
> Ooch, that hurts. How bad would it be if it was broken in 7.3?
We could dike out the feature:
convert_list:
a_expr USING any_name
Tom Lane wrote:
> We could dike out the feature:
>
> convert_list:
> a_expr USING any_name
> {
> elog(ERROR, "CONVERT(... USING ...) is not implemented");
> }
>
> Short of that, I think we need an initdb to change the function
> sign
> I have just noticed that the implementation of
> CONVERT(text USING encoding_name)
> tries to do database access during the grammar phase, viz it looks
> up the encoding_name in pg_conversion and replaces it with an OID.
>
> This is not workable; consider the situation where we are in an
>
10 matches
Mail list logo
