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
