Martijn van Oosterhout wrote:
> On Wed, Jul 19, 2006 at 06:06:08PM -0400, Eric Faulhaber wrote:
>> Martijn van Oosterhout wrote:
>>> On Wed, Jul 19, 2006 at 05:24:53PM -0400, Eric Faulhaber wrote:
>>>> OK, but now that this "feature" has been removed in 8.1.4, how is this
>>>> supposed to be handled, given that we don't control what string data
>>>> we're handed? How does psql deal with it?
>>> Well, bytea handles null like it always has. There must be a way to you
>>> to store strings into bytea columns... But I only have a vague
>>> understanding of why bytea won't work for you...
>> Collation, for one. Our runtime is extremely sensitive to the order in
>> which records are read, to the point where I've created a custom locale
>> just for the PostgreSQL cluster.
>>
>> Then there's case sensitivity, being able to use string functions in
>> SQL, etc., etc. Bottom line, these are valid strings, so we need to
>> treat them as such.
>
> 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?
Thanks,
Eric