Re: DatumGetInetP buggy
От | Boszormenyi Zoltan |
---|---|
Тема | Re: DatumGetInetP buggy |
Дата | |
Msg-id | 4EB978FD.1070301@cybertec.at обсуждение исходный текст |
Ответ на | Re: DatumGetInetP buggy (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: DatumGetInetP buggy
|
Список | pgsql-hackers |
2011-11-08 18:53 keltezéssel, Heikki Linnakangas írta: > On 08.11.2011 17:06, Tom Lane wrote: >> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes: >>> Hmm, it seems to be intentional, but I agree it's very much contrary to >>> the usual convention that DatumGetXXXP() returns a detoasted and >>> depacked datum. I think we should change it. I propose the attached >>> patch. It changes DatumGetInetP() to do PG_DETOAST_DATUM(), and adds new >>> DatumGetInetPP() macro to return the packed version. I also moved the >>> access macros like ip_family() from network.c to inet.h, so that they're >>> available for whoever wants to look at the fields without having to depack. >> >> No objection to making the DatumGet macro names conform to common >> convention, but I'm not thrilled with moving those special-purpose >> accessor macros into wider circulation. It's not necessary and the >> macros don't work unless used in a particular way per the comment, >> so I don't think they can be considered general purpose. > > Ok. > > What do people think of backpatching this? I'm inclined to backpatch, on the grounds > that the macro that detoasts and depacks should always work (ie. after this patch), even > if the depacking isn't necessary and introduces an extra palloc+copy, but the reverse is > not true. On the grounds that 9.0.x also shows the problem with the stock macro, backporting would be nice. I don't know which older trees may show the problem, I only tested with 9.0 and 9.1. -- ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
В списке pgsql-hackers по дате отправления: