| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Feng Tian <ftian(at)vitessedata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Decimal64 and Decimal128 |
| Date: | 2017-06-18 03:58:43 |
| Message-ID: | CAEepm=2jGRHgE4p0f1UHt0hdQgSi9fc5EXz=GR+F3hj2b_rxSw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> I feel like these would logically just be different types, like int4
>>> and int8 are. We don't have integer(9) and integer(18).
>>
>> Hmm. Perhaps format_type.c could render decfloat16 as decfloat(16)
>> and decfloat34 as decfloat(34), and gram.y could have a production
>> that selects the right one when you write DECFLOAT(x) and rejects
>> values of x other than 16 and 34.
>
> What would be the point of that?
We'd accept and display the new SQL:2016 standard type name with
length, but by mapping it onto different internal types we could use a
pass-by-value type when it fits in a Datum.
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2017-06-18 04:40:03 | Re: type cache for concat functions |
| Previous Message | Robert Haas | 2017-06-18 02:31:18 | Re: Decimal64 and Decimal128 |