Re: [HACKERS] Decimal64 and Decimal128
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Decimal64 and Decimal128 |
Дата | |
Msg-id | CA+Tgmob6hgF=gueh2B+fKAZ+8nJz3AZrv5_MzE0pBqybn-R_nw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Decimal64 and Decimal128 (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Decimal64 and Decimal128
|
Список | pgsql-hackers |
On Sat, Jun 17, 2017 at 11:58 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro >> <thomas.munro@enterprisedb.com> wrote: >>> On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas <robertmhaas@gmail.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. Uggh. I'll repeat what has been said on this mailing list many times before: the SQL standards committee often seems to make life unnecessarily difficult with its choice of syntax. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: