Auto selection of internal representation for integer NUMERIC

Started by ITAGAKI Takahiroalmost 20 years ago2 messageshackers
Jump to latest
#1ITAGAKI Takahiro
itagaki.takahiro@oss.ntt.co.jp

Hi Hackers,

I think about mapping NUMERIC(n) to fixed size integers corresponding to n:
- n < 4 to int2
- 5 <= n < 9 to int4
- 10 <= n < 18 to int8
- 19 <= n to original numeric

NUMERIC is not so efficient datatypes compared to fixed size integers.
If the auto selection is avaliable, users don't have to care about integer
types; they can always use NUMERICs.

In particular, this is useful for oracle users. Oracle recommends to use
NUMBER(n, p) for all the case where numerics are required. So they try to
use NUMERIC on PostgreSQL instead of NUMBER. But NUMERIC is not the best
alternative to a short integer NUMBER.

Is this worth trying and acceptable? This thought is not wanted if users
choise int2/4/8 carefully -- but it is rare case from my experience :-(
In addition, treating NaN value is an issue. NaN is supported on NUMERIC,
but there are complexities to do the same on fixed size integers.

Comments and suggestions are welcome.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: ITAGAKI Takahiro (#1)
Re: Auto selection of internal representation for integer NUMERIC

ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:

In particular, this is useful for oracle users. Oracle recommends to use
NUMBER(n, p) for all the case where numerics are required. So they try to
use NUMERIC on PostgreSQL instead of NUMBER. But NUMERIC is not the best
alternative to a short integer NUMBER.

I think the correct answer to that is user education. Anything along
the lines you are suggesting would be convoluted and would probably
introduce unexpected behaviors (eg, overflow of intermediate results
that wouldn't have overflowed if the data was really NUMERIC).

regards, tom lane