From: | "hernan gonzalez" <hgonzalez(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: text and bytea |
Date: | 2008-02-25 15:43:49 |
Message-ID: | 48692c2d0802250743y337d3cd1yad165a4770735bc0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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.
Sorry, my mistake. I meant the opposite:
convert_to() and convert_from() are the "correct" bridge (text <=>
bytea) functions.
Also convert() is ok.
The objetionable ones IMHO are decode()/encode(), which can
consume/produce a "non-utf8 string" (I mean, not the backend encoding)
Going back to the line:
encode(convert_to(c,'LATIN9'),'escape')
Here we have:
c => text (ut8)
convert_to(..). => bytea (represents a char sequence in latin9 encoding)
encode(...) => text (in latin9 encoding?)
Cheers
Hernán J. González
http://hjg.com.ar/
From | Date | Subject | |
---|---|---|---|
Next Message | Joris Dobbelsteen | 2008-02-25 15:51:13 | Re: Planner: rows=1 after "similar to" where condition. |
Previous Message | Tom Lane | 2008-02-25 15:33:57 | Re: Planner: rows=1 after "similar to" where condition. |