Re: Abbreviated keys for Numeric

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, 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-04-03 14:02:08
Message-ID: CA+TgmoZhoKWZoXDs59dHnUbpe8B7trQW-_vFoOdFO_6KN2xh_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 3, 2015 at 9:06 AM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> No, that's wrong; it must use USE_FLOAT8_BYVAL since that's what the
> >> definitions of Int64GetDatum / DatumGetInt64 are conditional on. As
> >> you have it now, it'll break if you build with
> >> --disable-float8-byval on a 64bit platform.
>
> Robert> I'd prefer to avoid that by avoiding the use of those macros in
> Robert> this code path rather than by leaving the top 32 bits of the
> Robert> Datum unused
>
> I don't consider it appropriate to override ./configure in this way.

I don't see how that's overriding configure. Commit
8472bf7a73487b0535c95e299773b882f7523463, which introduced
--disable-float8-byval in 2008, states that the motivation for this is
that it might break functions using the version 0 calling convention.
It should not propagate, like kudzu, into things that having nothing
to do with how values are passed to V0 functions. And as far as I can
see, the algorithm that we use to create an abbreviated key for
numeric is entirely decoupled from that question, because none of the
datums were are building here will ever get passed to one.

--
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-04-03 14:59:22 Re: Table-level log_autovacuum_min_duration
Previous Message Tom Lane 2015-04-03 14:01:23 Re: Possibly a typo in expand_inherited_rtentry()