Is it possible to store commas instead of points for decimal fields in a PostgreSQL database?
That has nothing to do with PostgreSQL. PostgreSQL does not store commas or points for decimal fields. It uses an internal number representation for numbers (int, floats, numeric).
If you need to format numeric information with PostgreSQL, you can use to_char function or use your client side programming language to format numbers.
Why? No programming language will accept decimals using comma's as a seperator. Presentation should be done in the presentation layer of your application, not in the storage layer.
http://www.php.net/manual/en/language.types.float.php
Related
I'm porting a procedure from Oracle to Postgres.
In select of a query, I have TO_CHAR(v_numeric, '990.000')
It seems, the same TO_CHAR(v_numeric, '990.000') works in Postgres with same result.
Can someone please explain what the '990.000' in the query does?
TO_CHAR(123.4, '990.000') returns 123.400 in both Oracle and Postgres. Whereas TO_CHAR(1234.400, '990.000') returns ######## in Oracle and ###.### in Postgres. Does this ######## and ###.### hold the same numeric value which is inputted?
to_char is a function to format a number as string for output. The PostgreSQL function is there expressly for Oracle compatibility, but it is not totally compatible, as you see.
The format 990.000 means that there will be one to three digits before the decimal point and three digits after it. 9 means that a value of 0 in that position will result in a blank rather than a 0.
The # characters signify that the number cannot be represented in that format. The reason is that there are more than three digits before the decimal point.
The resulting string does not "hold" a number, it is the rendering of a number as a string. It doesn't hold anything but the characters it consists of.
I'm working on obiee 12c rpd. I have a measure column in my physical table in DB with bigint data type. In physical layer of rpd, I've chosen its data type as numeric because int data type is so small for my values. Because of numeric data type, it's added '.00' at the end of my values. I used to remove them with round function in BMM layer's expression builder but it didn't work. I tried this steps with Changing the numeric to double data type in physical layer but I got the same result means I see values with .00 at the end in my dashboards.
Now I'm going to remove these zeros in rpd.
Is it possible? How can I do it?
Thanks
I agree with the answers above. If that doesn't seem to work, you could try to change the format to custom and work with a mask as explained here: https://docs.oracle.com/cd/E29542_01/bi.1111/e10544/format.htm#BIEUG10831
From oracle doc:
JDBC and the Administration Tool do not support this type (BIG INT);
therefore, Oracle BI EE does not fully support the BIG INT type. BI
Server does offer some support for this type, but BIG INT has not
been thoroughly tested with Oracle BI Server. The BIG INT type is
intended to be same as the C int64 data type.
Link:https://docs.oracle.com/cd/E28280_01/bi.1111/e10540/data_types.htm#BIEMG4602
Making it DOUBLE and sort the .00 issue inside the answers solves your problem ?
Go to column properties and data format, here is the window:
That's not how OBI works. The RPD is the number crunching engine. NOT the visualization part.
If you want the decimals to be hidden by default, then you set the data format with zero decimals by default. That's how the tool works. Not in the RPD.
I'm changing a column in the database from "money" to "numeric" per some previous advice here.
Looking through the data types in postgres -- https://www.postgresql.org/docs/current/static/datatype-numeric.html -- I can't see any differences between numeric and decimal in the descriptions.
What is the difference between decimal and numeric, and is there any reason I should use numeric instead of decimal for prices in my database?
According to the manual they are the same.
The types decimal and numeric are equivalent. Both types are part of
the SQL standard.
https://www.postgresql.org/docs/current/static/datatype-numeric.html
The difference lies in the SQL standard which allows for different behaviour:
NUMERIC must be exactly as precise as it is defined — so if you define 4 decimal places, the DB must always store 4 decimal places.
DECIMAL must be at least as precise as it is defined. This means that the database can actually store more digits than specified (due to the behind-the-scenes storage having space for extra digits). This means the database might store 1.00005 instead of 1.0000, affecting future calculations.
Difference between DECIMAL and NUMERIC
I'm using MONEY type for currency data in my Postgres table. When I select data, postgres formats values according to system's lc_monetary setting.
I would like to get rid of currency symbol in the query result without using explicit type casts (I'm using Laravel's query builder currently. Type casts will require raw queries).
Is there a way to setup lc_monetary config setting so that currency values in query results are formatted exactly like simple floats with 2-digit precision and without thousands separator (so that I would be able to use it as a string/float in my PHP code)?
Most people I have talked to reccommend not using the money type. Typically MONEY types get output as strings by your local implementation becuase of the LC_MONETARY formatting. Most people (myself included) recommend using a NUMERIC for your monetary values.
Also you mentioned placing your money values in a float. Floats on computers have rounding errors naturally and can cause issues with monetary amounts, so be careful.
In Python we use the decimal class when we need to do math on money, I assume that PHP has something similar.
Is select money_column/1::money safe...
According to the doc the result of dividing by money is double precision.... (The currency cancels out).
I am supporting an ETL process that transforms flat-file inputs into a SqlServer database table. The code is almost 100% T-SQL and runs inside the DB. I do not own the code and cannot change the workflow. I can only help configure the "translation" SQL that takes the file data and converts it to table data (more on this later).
Now that the disclaimers are out of the way...
One of our file providers recently changed how they represent a monetary amount from '12345.67' to '12,345.67'. Our SQL that transforms the value looks like SELECT FLOOR( CAST([inputValue] AS DECIMAL(24,10))) and no longer works. I.e., the comma breaks the cast.
Given that I have to store the final value as Decimal (24,10) datatype (yes, I realize the FLOOR wipes out all post-decimal-point precision - the designer was not in sync with the customer), what can I do to cast this string efficiently?'
Thank you for your ideas.
try using REPLACE (Transact-SQL):
SELECT REPLACE('12,345.67',',','')
OUTPUT:
12345.67
so it would be:
SELECT FLOOR( CAST(REPLACE([input value],',','') AS DECIMAL(24,10)))
This works for me:
DECLARE #foo NVARCHAR(100)
SET #foo='12,345.67'
SELECT FLOOR(CAST(REPLACE(#foo,',','') AS DECIMAL(24,10)))
This is probably only valid for collations/culture where the comma is not the decimal separator (ie: Spanish)
While not necessarily the best approach for my situation, I wanted to leave a potential solution for future use that we uncovered while researching this problem.
It appears that the SqlServer datatype MONEY can be used as a direct cast for strings with a comma separating the non-decimal portion. So, where SELECT CAST('12,345.56' AS DECIMAL(24,10)) fails, SELECT CAST('12,345.56' AS MONEY) will succeed.
One caveat is that the MONEY datatype has a precision of 4 decimal places and would require an explicit cast to get it to DECIMAL, should you need it.
SELECT FLOOR (CAST(REPLACE([inputValue], ',', '') AS DECIMAL(24,10)))