| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org |
| Subject: | Re: warning: HS_KEY redefined (9.5 beta2) |
| Date: | 2015-11-19 15:07:03 |
| Message-ID: | 7043.1447945623@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Erik Rijkers wrote:
>> make contrib:
>> In file included from hstore_plperl.c:6:0:
>> ../../contrib/hstore/hstore.h:79:0: warning: "HS_KEY" redefined
>> #define HS_KEY(arr_,str_,i_) ((str_) + HSE_OFF((arr_)[2*(i_)]))
> So we need to get this one fixed.
As for the HS_KEY conflict, I'm not too thrilled with the previous
suggestion of "#undef HS_KEY". That seems pretty fragile, ie it
depends on inclusion order. What do people think of doing
"s/HS_KEY/HSTORE_KEY/g"? (I guess this would also hit the
HS_KEYLEN macro for consistency.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-11-19 15:21:14 | Re: proposal: LISTEN * |
| Previous Message | Masahiko Sawada | 2015-11-19 14:44:05 | Re: Freeze avoidance of very large table. |