Psycopg difficulty...
От | Jerry LeVan |
---|---|
Тема | Psycopg difficulty... |
Дата | |
Msg-id | 804BD6B2-282E-11D9-9DDC-000393779D9C@eku.edu обсуждение исходный текст |
Список | pgsql-general |
Psycopg and probably PySQL seem to have decided to return a "float" type when libpq returns a string tagged with the "numeric" property. This can cause "pretty" printing problems when generating reports. ( I like all of my decimal points to line up.) For example in my python based browser if I try the command select 123.4500 I will get 123.45 and I have lost the scale. More over the description attribute for the cursor will contain 2^16 -1 for the precision and scale so that there is no way to recover the lost scale factor. For "regular" columns that have been declared with a numeric(9,2) attribute (as an example). then a select will leave in the cursor column description the proper values for the precision and scale and I can generate correct looking reports. However for "computed" columns in something like SELECT oid, *, (SELECT sum(amount) FROM checks WHERE x.oid >= oid ) AS total FROM checks x ORDER BY date,oid ; Assuming that amount is declared with numeric(9,2) the "total" column will have dropped any trailing zeros (ie 19.70 will display as 19.7). Basically computed columns do not furnish any info as to scale and precision The only way I can see to get around the problem is to cast the "total" column with the desired precision. SELECT oid, *, (SELECT sum(amount)::numeric(9,2) FROM checks WHERE x.oid >= oid ) AS total FROM checks x ORDER BY date,oid ; But I don't have to do the casting using libpq,pgsql,tcl, or perl-dbi interface. It seems like the right thing to do is to return the string value and let the user do the formatting like all of the other interfaces do... Jerry
В списке pgsql-general по дате отправления: