On Mon, Mar 23, 2015 at 8:54 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Mon, Mar 23, 2015 at 5:47 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I agree with you. Fewer and fewer people are running 32-bit systems
>> these days, but there must surely be more people running 32-bit
>> systems than there are running with DEC_DIGITS != 4. I think it's a
>> stretch to say that DEC_DIGITS != 4 is "supported" in any meaningful
>> sense, so I don't think de-supporting it is an issue.
>
> Of course Andrew's analysis is correct...very few people are building
> with DEC_DIGITS != 4. Maybe zero. That's beside the point, IMV, which
> is that it's less invasive to just keep the code the way it is.
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.
> Desupporting DEC_DIGITS != 4, by making the code break in a general
> way, without reference to this patch, seems misguided. I would like
> the build to break in a way that makes the customizer of numeric.c
> realize that they can disable abbreviation manually too, and still
> build with DEC_DIGITS != 4. Otherwise, you better remove all the
> existing specialized DEC_DIGITS != 4 code, of which there is a fair
> bit. I don't think it makes sense to call that code "historical".
That's a false dichotomy. We have a bunch of code lying around with
#ifdef NOT_USED around it, and that's not intended to imply that you
can build with -DNOT_USED. I admit to having not looked at the patch
yet, so I may have a clearer position on exactly what to do about this
once I've done that. But, as a general principle, I don't accept that
we must either keep the DEC_DIGITS != 4 case working in its entirety
or remove it completely.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company