From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | pgsql-general(at)postgresql(dot)org, Hans-Juergen Schoenig <hs(at)cybertec(dot)at> |
Subject: | Re: What is the correct way to extract values from an int8 array in SPI? |
Date: | 2009-11-16 15:14:33 |
Message-ID: | 19030.1258384473@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> // ids =
> PointerGetDatum(PG_DETOAST_DATUM(SPI_getbinval(prod_inv->vals[0],
> prod_inv->tupdesc, 1, &isnull)));
well, for one thing, you probably want DatumGetPointer ... for another,
you shouldn't really be converting to Pointer here at all, since the
next line expects ids to still be a Datum. On some platforms you can
get away with being fuzzy about the distinction between Datum and
Pointer, but it doesn't surprise me in the least that such code would
fail elsewhere. Try paying more attention to compiler warnings ;-)
The lack of any checks for null-ness scares me, too. Aside from the
multiple places where you're just plain ignoring an isnull return flag,
there's the risk that the array might contain one or more nulls, in
which case you can't address the last element that way (even if that
element itself isn't null).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-11-16 15:39:57 | Re: safelly erasing dirs/files |
Previous Message | Thom Brown | 2009-11-16 14:25:24 | Re: Comparing bit in an integer field |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-16 15:29:40 | Re: different result between 8.3 and 8.5 (to_timestamp function) |
Previous Message | Tom Lane | 2009-11-16 15:05:54 | Re: [HACKERS] pgsql: /home/peter/commit-msg |