> No I don't think it is crazy when you look at the other side of the
> coin. LargeObject's have their own set of problems and you need to
> compare the pros and cons of each solution. The reason I believe that
> bytea wins over LargeObjects is because of the symantics of delete.
I do agree here, LO's have their own insurmountable issues.
[snip]
> the oid for the LargeObject. The casual user of binary data (which can
> range from a few bytes to hundreds of megs) should have something out of
> the box that works symantically as they would expect IMHO.
I totally agree; however as shown the bytea type *will not work* for data
this size (esp. not hundreds of megs). Both storage and retrieval from the
client. !!
> I find that
> many users of bytea are storing gifs and html pages for web sites which
> generally are small enough such that bytea works fine.
Well, I disagree... even a few kilobytes has shown to be substandard in
storing.
> This is all explained to some degree in the documentation for 7.2. It
> is left as a choice to the user to use the datatype best suited for
> their circumstances given the pros and cons of the different
alternatives.
Again its not really well explained at all in the doco (I'm writing a
primer that fixes code bugs in the examples (setBlob() isn't a method ;)
and clarifies these issues). It is left as a choice I agree, but
defaulting to the bytea type IMHO is a shocking thing to do... if I hadn't
done this investigation and gone ahead with my application using 'bytea',
it would be brought to its knees, thats if it makes it to its knees after
the memory issues.
Joe