Re: numeric_to_number() function skipping some digits

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Jeevan Chalke" <jeevan(dot)chalke(at)enterprisedb(dot)com>, "daveg" <daveg(at)sonic(dot)net>
Cc: "Brendan Jurd" <direvus(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: numeric_to_number() function skipping some digits
Date: 2009-09-30 23:22:02
Message-ID: 4AC3A1CA020000250002B504@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

daveg <daveg(at)sonic(dot)net> wrote:
> On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
>>
>> It seems that Oracle reads formatting string from right-to-left.
>> Here are few results:
>> ('number','format') ==> Oracle PG
>> --------------------------------------------
>> ('34,50','999,99') ==> 3450 340
>> ('34,50','99,99') ==> 3450 3450
>> ('34,50','99,999') ==> Invalid Number 3450
>> ('34,50','999,999') ==> Invalid Number 340
>
> It seems worse to to give a wrong answer silently then to throw an
> error. What we do now seems sort of MySqlish.

I agree with David on that.

Further, it seems to me that functions which are there only for Oracle
compatibility (i.e., they are not part of the SQL standard and are not
particularly sensible, but are popular in Oracle) should behave like
the corresponding Oracle function. An argument could even be made for
"bug compatibility" for such functions, at least to some extent;
although we're not talking about that here -- the Oracle results seem
more sane than current PostgreSQL behavior..

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-30 23:27:44 Re: numeric_to_number() function skipping some digits
Previous Message Andrew Gierth 2009-09-30 22:55:33 Re: latest hstore patch