Martijn van Oosterhout wrote:
> 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
