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.

  >>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.

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?


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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to