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.
Related
I looked though the forum but I couldn't find a issue like mine.
Essentially I have a table called [p005_MMAT].[dbo].[Storage_Max]. It has three columns Date, HistValue and Tag_ID. I want to make all the values in 'HistValue' column to have 2 decimal places. For example if a number is 1.1, I want it to be 1.10 or if its 1 then also I want it to look like 1.00.
Here is the sql update statement I am using
update [p005_MMAT].[dbo].[Storage_Max]
set [HistValue] = cast([HistValue] as decimal (10,2))
where [Tag_ID] = 94
After executing the query it says 3339 rows affected but when I perform a simple select statement it appears the column had no affect of. I have used that cast function in select statement and it adds two decimal places.
Please advice.
The problem is the datatype and SQL Server. Float or real will not have the trailing zeros. You either have to change the datatype of the column or just deal with it and handle the formatting in your queries or application.
You could run something like the following
select
cast([HistValue] as decimal (10,2))
from [p005_MMAT].[dbo].[Storage_Max]
where [Tag_ID] = 94
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
am new to postgresql (redshift)
i am copying CSV files from S3 to RedShift and there's an error about trying to save 2.35555E7 number into a numeric | 18, 0 column . what is the right datatype for this datum ?
thanks
numeric (18,0) implies a scale of zero, which is a way of saying no decimals -- it's a bit like a smaller bigint.
http://www.postgresql.org/docs/current/static/datatype-numeric.html
If you want to keep it as numeric, you want to use numeric instead -- with no precision or scale.
If not, just use a real or a double precision type, depending on the number of significant digits (6 vs 15, respectively) you want to keep around.
Your example data (2.35555E7) suggests you're using real, so probably try that one first.
Note: select 2.35555E7::numeric(18,0) works fine per the comments, but I assume there's some other data in your set that is causing issues.
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
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)))