Re: text and bytea

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/

In response to

Responses

Browse pgsql-general by date

  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.