|
|
|
|
|
|
| Author |
Message |
Martijn van Oosterhout *nix forums Guru
Joined: 02 Mar 2005
Posts: 674
|
Posted: Thu Jul 20, 2006 7:47 pm Post subject:
Re: UTF8 conversion differences from v8.1.3 to v8.1.4
|
|
|
On Thu, Jul 20, 2006 at 12:07:54PM -0400, Eric Faulhaber wrote:
| Quote: | 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@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate. |
|
| Back to top |
|
 |
Eric Faulhaber *nix forums beginner
Joined: 18 Jul 2006
Posts: 8
|
Posted: Thu Jul 20, 2006 8:06 pm Post subject:
Re: UTF8 conversion differences from v8.1.3 to v8.1.4
|
|
|
Martijn van Oosterhout wrote:
| Quote: | 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,
|
I see, thanks for the suggestion.
I'm also considering requiring UTF8 encoding at the server to make the
database consistent with the JDBC client. I suppose this also would
bypass the encoding check...
But I'm concerned that both approaches just delay the inevitable. If
the PG roadmap is to close all of these embedded null "loopholes" rather
than supporting these strings as first class citizens, I expect that a
future version will cut me off at the knees again when I least expect it :-(
Thanks,
Eric
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Mon Dec 01, 2008 8:47 pm | All times are GMT
|
|
Project cars for sale | Apply for Credit Card | Loans | Mortgage Calculator | Internet Advertising
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|