Converting a code from oracle to postgres,But ABS() function showing different format result. How to get exact format as oracle.
ORACLE
SQL> select ABS(0.00) from dual;
0
SQL> select ABS(-2.05) from dual;
2.05
SQL> select ABS(2.50) from dual;
2.5
Postgres
select abs(0.00)
0.00
select abs(-2.05)
2.05
select abs(2.50)
2.50
The difference you observe is insignificant and is just caused by a different way to display numeric data: PostgreSQL shows as many zeros as the scale of the type decrees.
If you want numbers to appear in a certain format, always format them using to_char().
use ::REAL in postgres
use :: operator to convert decimal number containing trailing zeros to a number without additional zeros.
example:
select abs(2.50)::REAL;
Related
The dump function in Oracle displays the internal representation of data:
DUMP returns a VARCHAR2 value containing the data type code, length in bytes, and internal representation of expr
Fore example:
SELECT DUMP(cast(1 as number ))
2 FROM DUAL;
DUMP(CAST(1ASNUMBER))
--------------------------------------------------------------------------------
Typ=2 Len=2: 193,2
SQL> SELECT DUMP(cast(1.000001 as number ))
2 FROM DUAL;
DUMP(CAST(1.000001ASNUMBER))
--------------------------------------------------------------------------------
Typ=2 Len=5: 193,2,1,1,2
It shows that the first 1 uses 2 byte for storing and the second example uses 5 bytes for storing.
I suppose the similar function in PostgreSQL is pg_typeof but it returns only the type name without information about byte usage:
SELECT pg_typeof(33);
pg_typeof
integer (1 row)
Does anybody know if there is an equivalent function in PostgreSQL?
I don't speak PostgreSQL.
However, Oracle functionality page says that there's Orafce which
implements in Postgres some of the functions from the Oracle database that are missing (or behaving differently)
It, furthermore, mentions the dump function
dump (anyexpr [, int]): Returns a text value that includes the datatype code, the length in bytes, and the internal representation of the expression
One of examples looks like this:
postgres=# select pg_catalog.dump('Pavel Stehule',10);
dump
-------------------------------------------------------------------------
Typ=25 Len=17: 68,0,0,0,80,97,118,101,108,32,83,116,101,104,117,108,101
(1 row)
To me, it looks like Oracle's dump:
SQL> select dump('Pavel Stehule') result from dual;
RESULT
--------------------------------------------------------------
Typ=96 Len=13: 80,97,118,101,108,32,83,116,101,104,117,108,101
SQL>
I presume you'll have to visit GitHub and install the package to see whether you can use it or not.
It is not a complete equivalent, but if you want to figure out the byte values used to encode a string in PostgreSQL, you can simply cast the value to bytea, which will give you the bytes in hexadecimal:
SELECT CAST ('schön' AS bytea);
This will work for strings, but not for numbers.
How can I set numeric display format in psql?
I have many character varying and double precision columns in the select query. I can use to_char() or round() on each of the numeric columns, but with many columns this makes the code too repetitive.
Is there a shortcut? For example, are there any psql session settings, something like \pset numeric '9.9EEEEE' (I just made it up, don't try to use it). I could not quickly find such settings in the manual: PostgreSQL: Documentation: psql.
Example:
-- Got this:
=# select bar from (values (123456789), (0.123456789), (0.000000123456789)) table_foo (bar);
bar
-------------------
123456789
0.123456789
0.000000123456789
-- I have to use this workaround:
=# select to_char(bar, '9.9EEEEE') as bar from (values (123456789), (0.123456789), (0.000000123456789)) table_foo (bar);
bar
----------
1.2e+08
1.2e-01
1.2e-07
-- I want this:
-- set some session settings, and then magically:
=# select bar from (values (123456789), (0.123456789), (0.000000123456789)) table_foo (bar);
bar
----------
1.2e+08
1.2e-01
1.2e-07
There is not other possibility to specify number of format then specification of numeric locale. Values are formatted on server side already, psql does formatting to final output format (table, html, csv), but the values are formatted, and psql doesn't try to do reformat (numericlocale is an exception). I remember long discussion about possibility to specify output format of boolean type, but still without actual results. psql has not strong functionality for generating rich reports. It should be fast, safe and robust interactive client. Although I would to have some stronger possibility in this area, the modern spreadsheets and reporting tools are for some tasks better.
You could always define your own formatting function, but you'd have to be doing a lot of formatting on a lot of columns for this to be considered an improvement in readability. I wouldn't recommend it for your toy example but if your real queries have dozens of columns it might be neater.
sophia=> create function x(numeric) returns text language sql as $$ select to_char($1, '9.9EEEEE') $$;
CREATE FUNCTION
sophia=> select x(bar) from (values (123456789), (0.123456789), (0.000000123456789)) table_foo (bar);
x
----------
1.2e+08
1.2e-01
1.2e-07
(3 rows)
sophia=>
I found an issue of Postgres decimal places auto become 6 places when try to insert data from SQL Server into Postgres using OPENQUERY.
I have searched many references that suggested using CAST or Convert to limit decimal places from SQL Server, everything is work fine when I just tried select from the SQL Server side (It is 0.001), but whenever run the query like below, in Postgres (for example the 'Rounding' will become 0.001000).
For example:
INSERT INTO OPENQUERY(RND,
'SELECT
name,
rounding
FROM test.public.product_uom')
SELECT
UoMID,
0.001
FROM dbo.tUoM
WHERE UoMID IN ('YEAR', 'ZAK');
The expected result that I would like is to have the same value of Rounding when Insert into from SQL Server to Postgres that is 0.001. Any help or suggestions will be appreciated and thanks in advance.
How to trim the column in DB2 for the below given input
00652835065718
00052835065718
I need to use SQL to remove all leading zeros from the values so that the final output will be:
652835065718
52835065718
The Column is VARCHAR
I have tried the below query
select TRIM(L '0' FROM ID) from ITM where ID = '0652835065718'
but it's not working in my DB2 version 9.1.5
The answer depends on your DB2 Platform
If you're on DB2 for Linux/Unix/Windows, then the answer is similar to what #Teun Loonen said, I'm guessing that it's the backticks that are messing things up. The correct syntax for the TRIM function on DB2 is:
SELECT TRIM(LEADING '0' FROM ID)
FROM ITM
If you're on Mainframe DB2, then you can use the LTRIM scalar function:
SELECT LTRIM(ID, '0')
FROM ITM
DB2 will automatically remove leading 0s from Integers so just use CAST, like this:
SELECT CAST(ID AS INTEGER)
Here is a test.
SELECT CAST('0012345' AS INTEGER) FROM SYSIBM.SYSDUMMY1
1
-----------
12345
by simply using the trim function
select TRIM( LEADING '0' FROM `field` ) as field FROM table
edit: removed link
What is the type that sql server assigns to the numeric literal: 2. , i.e. 2 followed by a dot?
I was curious because:
select convert(varchar(50), 2.)
union all
select convert(varchar(50), 2.0)
returns:
2
2.0
which made me ask what's the difference between 2. and 2.0 type wise?
Sql server seems to assign types to numeric literals depending on the number itself by finding the minimal storage type that can hold the number. A value of 1222333 is stored as int while 1152921504606846975 is stored as big int.
thanks
Edit: I also want to add why this is so important. In sql server 2008 r2, select 2/5 returns 0 while select 2./5 returns 0.4, due to the way sql server treats these types. In oracle and Access select 2/5 (oracle: select 2/5 from dummy) returns 0.4. That's the way it should be. I wonder if they fixed this behaviour in sql server 2012. I would be surprised if they did.
This script might answer my question. The type of 2. is numeric(1, 0).
create table dbo.test_type (field sql_variant)
go
delete from dbo.test_type
go
INSERT INTO dbo.test_type
VALUES (2.);
INSERT INTO dbo.test_type
VALUES (2.0);
SELECT field
, sql_variant_property (field
, 'BaseType')
AS BaseType
, sql_variant_property (field
, 'Precision')
AS Precision
, sql_variant_property (field
, 'Scale')
AS Scale
FROM dbo.test_type
It returns:
2 numeric 1 0
2.0 numeric 2 1
This is why when 2.0 is converted to varchar the result is 2.0. Sql server seems to record the precision.