From: | "hernan gonzalez" <hgonzalez(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: text and bytea |
Date: | 2008-02-25 12:52:30 |
Message-ID: | 48692c2d0802250452s1bf50c92we5aa23e91b34aaf0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Umm, I think all you showed was that the to_ascii() function was
> broken. Postgres knows exactly what encoding the string is in, the
> backend encoding: in your case UTF-8.
That would be fine, if it were true; then, one could assume that every
postgresql function that returns a text gets ALWAYS the standard
backend encoding (again: as in Java). But consider the result
postgresql gets from this (from my example):
encode(convert_to(c,'LATIN9'),'escape')
That's something of type text (a strign), postgresql believes it's
UTF8, but it's not (it probably woud not even validate as a valid
utf8 sequence).
IMHO, the semantics of encode() and decode() are correct (the bridge
between bytea and text ... in the backend encoding; they should be the
only bridge), convert() is also ok (deals with bytes), but
convert_to() and convert_from() are dubious if not broken: they imply
texts in arbitrary encodings (for output or input) , lead to
anomalities and shouldnt be necessary at all.
Cheers
Hernán J. González
http://hjg.com.ar/
From | Date | Subject | |
---|---|---|---|
Next Message | Obe, Regina | 2008-02-25 14:43:19 | HOW does 8.3 CREATE REPLACe .. FUNCTION ..COST work |
Previous Message | Joris Dobbelsteen | 2008-02-25 12:13:37 | Re: Planner: rows=1 after "similar to" where condition. |