Dave,
I share your concerns about this functionality. In fact last month I
wrote the following in response to a patch to this functionality.
I wouldn't mind this being pulled out of the main code line for now and
moved to contrib until it becomes more robust.
>>Robert,
>>
>>
>>Thanks for the patch. While I didn't review it too closely, what I
>>saw seemed fine.
>>
>>However, I have concerns about the feature as a whole, which really
>>has nothing to do with your patch.
>>
>>I don't like the approach taken here for serialization. It seems to
>>me that this is a half baked attempt to reimplement native java
>>serialization. Why not just use java serialization to do what it was
>>intended for? We could then store the results of the serialization in
>>a bytea column, or a LargeObject, or even in a separate table as is
>>done here. However, I am unsure of the desireabilty of creating these
>>additional tables. The bigest reason I don't like the additional
>>tables is that the serialized objects don't ever get deleted.
>>
>>To the extent that this is documented, I think the feature should be
>>marked as experimental with a caution that it may be changed in major
>>non-backwardly compatible ways in the future.
>>
>>thanks,
>>--Barry
There are two areas in the current code that I am uncomfortable with.
This serialize code and the code in org/postgresql/xa. Have you looked
at the xa code?
thanks,
--Barry
Dave Cramer wrote:
> While fixing the handling of "unknown" data type in the result set I was
> faced with wading through the Serialize code.
>
> I am wondering if this is really a required/desireable feature?
>
> How many people out there are actually using it?
>
> Do we need/want it?
>
> My thoughts are:
>
> 1) There are plenty of persistence layers which do this job much better.
>
> 2) I don't think this belongs in a driver.
> 3) The code will be simpler.
>
> Dave
>
>
