| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-bugs(at)postgresql(dot)org, Martin Atukunda <matlads(at)gmail(dot)com> |
| Subject: | Re: BUG #5784: CREATE INDEX USING GIN complains about array containing null values yet none exist |
| Date: | 2010-12-05 17:26:45 |
| Message-ID: | 26741.1291570005@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On Sunday 05 December 2010 17:42:59 Tom Lane wrote:
>> I think the reason the given example fails is just that it's all being
>> done in one transaction. If the null-containing row were known dead
>> it wouldn't get indexed. So: commit.
> Um I doubt it.
[ gets out gdb... ] Oh: the reason GIN is complaining is that it's just
looking at ARR_HASNULL(), and the array's has-nulls flag is still set
because we don't bother to try to clear it after replacing one element
of the array. (Which in general would be an expensive thing to try to
do...)
If we were intending to leave GIN in its current nulls-hating state,
the thing to do would be to replace the stupid ARR_HASNULL check with
something more intelligent. But really it needs to be fixed to handle
nulls properly, so I'm thinking that might be a dead-end patch.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martin Atukunda | 2010-12-05 19:06:21 | Re: BUG #5784: CREATE INDEX USING GIN complains about array containing null values yet none exist |
| Previous Message | Peter Eisentraut | 2010-12-05 17:10:06 | Re: BUG #5783: plpythonu bool behavior change |