Re: Abbreviated keys for Numeric

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
Subject: Re: Abbreviated keys for Numeric
Date: 2015-03-24 02:36:37
Message-ID: CA+Tgmob-__rENx5-QVKGMMhh_na4q_LCShhsn5_3zVr4znaVQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 23, 2015 at 9:12 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Mon, Mar 23, 2015 at 6:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Well, not committing the patch at all would be even less invasive.
>> But that's true of any patch, so I don't think being less invasive can
>> be the prime goal. Of course it's usually better to be less invasive
>> and get the same benefits, but when being less invasive means getting
>> fewer benefits, the additional invasiveness has to be weighed against
>> what you get out of it.
>
> I agree with that principle. But desupporting DEC_DIGITS != 4 as
> Andrew proposed gives no clue to how it can be worked around should
> someone want DEC_DIGITS != 4, as was once anticipated. Whereas a
> simple static assertion gives us that flexibility, with two lines of
> code, and without either removing or rendering entirely dead
> considerable swathes of numeric.c. You can argue that the code was
> dead anyway, but Tom didn't seem to feel that way when he wrote it.
> Why mess with that? There is no benefit to doing so.

I'll wait to comment on this until I have a few minutes to read TFP.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-03-24 02:46:21 Re: Table-level log_autovacuum_min_duration
Previous Message Andrew Gierth 2015-03-24 02:33:26 Re: Exposing PG_VERSION_NUM in pg_config