Re: Remove configure --disable-float4-byval and --disable-float8-byval

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove configure --disable-float4-byval and --disable-float8-byval
Date: 2019-11-13 12:36:27
Message-ID: CA+TgmoahOo7-f+rP9UJEcFzyQxs6qQRadUwreaNtF31GJcZSOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 2, 2019 at 8:00 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think we really ought to remove the difference behind macros. That is,
> for types that could be either, provide macros that fetch function
> arguments into local memory, independent of whether the argument is a
> byval or byref type. I.e. instead of having separate #ifdef
> USE_FLOAT8_BYVALs for DatumGetFloat8(), DatumGetInt64(), ... we should
> provide that logic in one centralized set of macros.
>
> The fact that USE_FLOAT8_BYVAL has to creep into various functions imo
> is the reasons why people are unhappy about it.

I think I'm *more* unhappy about the fact that it affects a bunch of
things that are not about whether float8 is passed byval. I mean, you
mention DatumGetInt64() above, but why in the world does a setting
with "float8" in the name affect how we pass int64? The thing is like
kudzu, getting into all sorts of things that it has no business
affecting - at least if you judge by the name - and for no really
clear reason.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-11-13 13:08:23 Re: ssl passphrase callback
Previous Message Amit Kapila 2019-11-13 12:25:04 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions