Re: Rounding to even for numeric data type

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Rounding to even for numeric data type
Дата
Msg-id CAB7nPqQuZL8XGiDDxZREkpiLJTDKGQODrfZvsNDDRJ=f9wjoFw@mail.gmail.com
обсуждение исходный текст
Ответ на Rounding to even for numeric data type  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Apr 22, 2015 at 9:30 PM, Pedro Gimeno
<pgsql-004@personal.formauri.es> wrote:
> Dean Rasheed wrote, On 2015-03-28 10:01:
>> On 28 March 2015 at 05:16, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>>>
>>>  Tom> I think the concern over backwards compatibility here is probably
>>>  Tom> overblown; but if we're sufficiently worried about it, a possible
>>>  Tom> compromise is to invent a numeric_rounding_mode GUC, so that
>>>  Tom> people could get back the old behavior if they really care.
>>>
>>> I only see one issue with this, but it's a nasty one: do we really want
>>> to make all numeric operations that might do rounding stable rather than
>>> immutable?
>>>
>>
>> Yeah, making all numeric functions non-immutable seems like a really bad idea.
>
> Would it be possible to make it an unchangeable per-cluster or
> per-database setting, kinda like how encoding behaves? Wouldn't that
> allow to keep the functions immutable?

Rounding is not something that can be enforced at the database or
server level but at data type level, see for example the differences
already present for double precision and numeric as mentioned
upthread. In short, you could keep rounding functions immutable by
having one data type with a different rounding method. At least that's
an idea.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Improve sleep processing of pg_rewind TAP tests
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Seq Scan