thierry@nekhem.com wrote:
Hi,
The problem is inside postgresql ! They use OID type for LOB and for table'oid, PoPy (to simplify LOB handling) detect automagically LOB and returns them to the end user who can handle them easily. I study the postgresql sources on the CVS and they haven't resolv this problem. We have to write this in the BUGS file we plan to add soon in our release.
If you have any proposals to resolv this BIG problem ?
I'm sorry for this but postgresql types are very confused.
Best regards.
So, if I understand correctly, oids are handled as large binary objects?
From what I see, oids are 6 bytes in length (using SELECT length(oid)...) since they have a max value of 4 billion, that leads me to believe that only 4 bytes are used as a numeric value. So, they are really just a glorified int4 with 2 extra bytes tacked on for some reason.
Anyhow, why exactly does this cause PoPy to crash? I can surely work around this problem for now, but I can certainly see cases where returning an oid would be an essential function, especially if you are working on a generalized database tool. I am certainly willing to help get this fixed. Any additional information you (or anybody) has regarding this would be greatly appreciated. Thanks for your help. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
Actually I found that the Postgres length function returns the string length (i.e. number of digits) of a number, so my previous message was wrong about the byte length of an oid. AFAIK they are 4 byte integers. I have found a way to retrieve oids without crashing Python or Zope. You must do an explicit type conversion to a 4 byte integer like so: SELECT int4(oid) FROM foo; This behaves in a much friendlier manner. I would still like to see the problem resolved, as I find the fact that an innocuous SELECT query could crash Zope a bit troubling. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
participants (1)
-
Casey Duncan