| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Bug in intarray? |
| Date: | 2012-02-17 00:27:57 |
| Message-ID: | 6294.1329438477@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> This query:
> SELECT ARRAY[-1,3,1] & ARRAY[1, 2];
> should give {1} as a result.
> But, on HEAD (and according to his tests, on 9.0.6 and 9.1.2), it
> appears to give en empty array.
Definitely a bug, and I'll bet it goes all the way back.
> Digging on this issue, another user (Julien Rouhaud) made an interesting
> comment on this line of code:
> if (i + j == 0 || (i + j > 0 && *(dr - 1) != db[j]))
> (line 159 of contrib/intarray/_int_tool.c, current HEAD)
> Apparently, the code tries to check the current value of the right side
> array with the previous value of the resulting array. Which clearly
> cannot work if there is no previous value in the resulting array.
> So I worked on a patch to fix this, as I think it is a bug (but I may be
> wrong). Patch is attached and fixes the issue AFAICT.
Yeah, this code is bogus, but it's also pretty unreadable. I think
it's better to get rid of the inconsistently-used pointer arithmetic
and the fundamentally wrong/irrelevant test on i+j, along the lines
of the attached.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| inner_int_inter-2.patch | text/x-patch | 2.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shigeru Hanada | 2012-02-17 00:52:50 | Re: pgsql_fdw, FDW for PostgreSQL server |
| Previous Message | Dan Scales | 2012-02-17 00:17:27 | Re: possible new option for wal_sync_method |