| 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: | Whole Thread | Raw Message | 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. |