From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Eric Faulhaber <ecf(at)goldencode(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: UTF8 conversion differences from v8.1.3 to v8.1.4 |
Date: | 2006-07-20 19:47:35 |
Message-ID: | 20060720194735.GC26339@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Jul 20, 2006 at 12:07:54PM -0400, Eric Faulhaber wrote:
> > Well, there's a really nasty workaround: create a cast from bytea to
> > text which doesn't change the value. This will get your data into the
> > database without any encoding checks at all. Ofcourse, you're then
> > responsible for any problems caused down the line...
> >
> > Have a nice day,
>
> Not sure I understand... at what point is the cast performed and what
> type is actually stored in the database: text or bytea?
Well, the point is that there is actually no difference in how bytea
and text are stored. What you do is use a type-cast to relabel the data
to be text. So the fields in the database would be marked type text but
the data would be transferred there as bytea.
This doesn't fix the fact that the text functions can't handle embedded
nulls, but it's a workaround. Note that you bypass all encoding checks
this way so you're kind on of your own if it acts odd...
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Jasbinder Bali | 2006-07-20 19:53:10 | calling stored procedure using ECPG |
Previous Message | Dan Strömberg | 2006-07-20 18:21:15 | Column info without executing query |