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 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/

In response to

Responses

Browse pgsql-general by date

  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.