Re: Abbreviated keys for Numeric
От | Andrew Gierth |
---|---|
Тема | Re: Abbreviated keys for Numeric |
Дата | |
Msg-id | 87lhiavszn.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Abbreviated keys for Numeric (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Abbreviated keys for Numeric
|
Список | pgsql-hackers |
>>>>> "Robert" == Robert Haas <robertmhaas@gmail.com> writes: Robert> I think this is really nice work, so I have committed thisRobert> version. I made a few fairly minor changes, hopefullywithoutRobert> breaking anything in the process: Robert> - I adjusted things for recent commits around INT{32,63}_{MIN_MAX}.Robert> - I removed (void) ssup; which I do notthink is normal PostgreSQL style.Robert> - Removed the #if DEC_DIGITS != 4 check. The comment is great, but IRobert>think we don't need protect against #if 0 code get re-enabled. No complaints in principle for any of these Robert> - I removed the too-clever (at least IMHO) handing of TRACE_SORT inRobert> favor of just using #ifdef around eachoccurrence. My idea here - which I have admittedly not got round to posting a patch for yet - was that TRACE_SORT (which has been defined by default since 8.1) should be deprecated in favour of unconditional use of trace_sort. (The actual definition of TRACE_SORT could be kept in case any extension or whatever uses it) Robert> - I also declared trace_sort in guc.h, where various other GUCsRobert> are declared, instead of declaring it privatelyin each fileRobert> that needed it. I was thinking miscadmin.h but whatever. Robert> - Changed some definitions to depend on SIZEOF_DATUM ratherRobert> than USE_FLOAT8_BYVAL. Hopefully I didn't muffthis; pleaseRobert> check it. 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. -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: