Re: Abbreviated keys for Numeric

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Abbreviated keys for Numeric
Дата
Msg-id CA+TgmoZhoKWZoXDs59dHnUbpe8B7trQW-_vFoOdFO_6KN2xh_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Abbreviated keys for Numeric  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: Abbreviated keys for Numeric  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
On Fri, Apr 3, 2015 at 9:06 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmhaas@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Possibly a typo in expand_inherited_rtentry()
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Table-level log_autovacuum_min_duration