I am looking to do some work on adding one or two extra column types to address
the reflection issues with legacy Postgres databases that I'm having. One of
those is the double precision/float8 type. I notice that the current float
inherits from Numeric and expects a precision and a length. In Postgres at
least, a float can take a precision (in >v7.4 it is interpreted a binary digit
count and a value <=24 is assigned to a real/float and >24 to a double/float8)
but it doesn't understand a length.
So, I'm thinking we should change the existing float to inherit from a new base,
which just understands precision. There are 1 or 2 tests where a FLOAT(x,y) is
used but I'm more concerned that this change may break other code, particularly
where it has been used with the assumption that it would end up as a numeric in
the db.
So, what do people think - is separating float from numeric a reasonable and
safe thing to do at this point or not? If not, what alternatives do you suggest?
Robert
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
