Re: [HACKERS] taking stdbool.h into use
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] taking stdbool.h into use |
Дата | |
Msg-id | 20180116061157.GD2212@paquier.xyz обсуждение исходный текст |
Ответ на | Re: [HACKERS] taking stdbool.h into use (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] taking stdbool.h into use
|
Список | pgsql-hackers |
On Thu, Jan 11, 2018 at 06:40:05PM -0500, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> That leaves the uses in rowtypes.c. Those were introduced as a >> portability fix by commit 4cbb646334b. I'm curious why these are >> necessary. The Datums they operate come from heap_deform_tuple(), which >> gets them from fetchatt(), which does run all pass-by-value values >> through the very same GET_X_BYTES() macros (until now). I don't see >> where those dirty upper bits would be coming from. > > I don't see it either. I think the actually useful parts of that patch > were to declare record_image_cmp's result correctly as int rather than > bool, and to cope with varlena fields of unequal size. Unfortunately > there seems to be no contemporaneous mailing list discussion, so > it's not clear what Kevin based this change on. This was a hotfix after a buildfarm breakage, the base commit being f566515. > Want to try reverting the GET_X_BYTES() parts of it and see if the > buildfarm complains? So, Peter, are you planning to do so? > Note if that if we simplify the GetDatum macros, it's possible that > record_image_cmp would change behavior, since it might now see signed not > unsigned values depending on whether the casts do sign extension or not. > Not sure if that'd be a problem. Based on the patch series in https://www.postgresql.org/message-id/d86ec1f4-941c-e702-b05a-748ea2e59e9c@2ndquadrant.com, the next thing that could be shipped is 0003 in my opinion, as 0002 has already been pushed. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: