yah with the typing module, I focused on the overall architecture of types and the way they are structured and related between their generic version and their database specific version, and the way they process data.
but the decisions I made with regards to the specific types themselves are rough and not deeply researched, the way you have done below, so I am basically open to everyone's suggestions and pointers on specific types. I think I derived my numeric system from that of Oracle which filters decimal,numeric,float,integer, and real all into NUMBER. But if a float is usually defined as FLOAT and not a special case of NUMBER/NUMERIC, and generally considered to have just the one parameter, it makes sense to add a Float base type to types.py alongside Numeric, and then to all the DB modules to add corresponding database-specific float types, i.e. PGFloat, OracleFloat, MSFLoat, SQFloat. Robert feel free to give these changes a shot, and ill adjust as necessary. Other changes in this area might involve splitting out NUMERIC and DECIMAL and maybe having all of these types derive from a common NUMBER class, but lets start with the FLOAT. - mike Robert Leftwich wrote: > 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 > ------------------------------------------------------- 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
