Thread: DETOAST Datum
Hi,<br />I have defined some function and also used NDBOX structure that having variable length.<br /><br />typedef structNDBOX<br />{<br /> int32 vl_len_; /* varlena length */<br /> unsigned int dim;<br /> double x[1];<br /> } NDBOX;<br /><br />When i called my function, it gives NDBOX to be null<br />On debugging, i foundout ,FunctionInvokeCall invokes fmgr_oldstyle function, for getting argument<br /><br />if (fnextra->arg_toastable[i]) //this returns false, not able to get arguments<br /> fcinfo->arg[i] = PointerGetDatum(PG_DETOAST_DATUM(fcinfo->arg[i]));<br/> } <br /><br />"How to get arguments toastable??" and even mytable pg_class.reltoastrelid entry is zero.<br />Can i have to tell explicitly to toast?<br /><br />If i commented thatif conditions then, it got stuck below:<br /><br />struct varlena *<br />pg_detoast_datum(struct varlena * datum)<br/>{<br /> if (VARATT_IS_EXTENDED(datum)) //My code get stuck here<br /> return heap_tuple_untoast_attr(datum);<br/> else<br /> return datum;<br />}<br /><br />Can anyone tell me what VARATT_IS_EXTENDED(datum)mean?<br /><br />Thanks<br />
On Mon, May 16, 2011 at 3:41 AM, Nick Raj <nickrajjain@gmail.com> wrote: > When i called my function, it gives NDBOX to be null > On debugging, i found out ,FunctionInvokeCall invokes fmgr_oldstyle > function, for getting argument > > if (fnextra->arg_toastable[i]) //this returns false, not able to get > arguments > fcinfo->arg[i] = > PointerGetDatum(PG_DETOAST_DATUM(fcinfo->arg[i])); > } > > "How to get arguments toastable??" and even my table pg_class.reltoastrelid > entry is zero. It's pretty hard to guess what's going wrong here from the information you've provided. But reltoastid should not be 0 if you're using a variable-length data type. It's not exactly clear what you've done wrong though. Are you sure that the type is defined properly, as a variable-length type? > Can i have to tell explicitly to toast? No, you don't have to tell it that. > If i commented that if conditions then, it got stuck below: > > struct varlena * > pg_detoast_datum(struct varlena * datum) > { > if (VARATT_IS_EXTENDED(datum)) //My code get stuck here > return heap_tuple_untoast_attr(datum); > else > return datum; > } > > Can anyone tell me what VARATT_IS_EXTENDED(datum) mean? VARATT_IS_EXTENDED() returns true for datums that can be detoasted, because they are (1) they are stored out-of-line in the TOAST table, (2) compressed, or (3) unaligned, using a 1-byte header. See src/include/postgres.h. But I seriously doubt that you need to debug pg_detoast_datum(). If you're getting a failure there, it's because something wasn't done right much earlier on in the process. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, May 16, 2011 at 3:41 AM, Nick Raj <nickrajjain@gmail.com> wrote: >> "How to get arguments toastable??" and even my table pg_class.reltoastrelid >> entry is zero. > It's pretty hard to guess what's going wrong here from the information > you've provided. But reltoastid should not be 0 if you're using a > variable-length data type. It could be if the type is not marked toastable (ie, has storage class PLAIN, which I think is the default even for varlena types). But in any case I suspect that 90% of the problem here is an incorrect declaration of the *function* not the type. We haven't seen the C function declaration, nor the SQL CREATE FUNCTION command, but if it's going through fmgr_oldstyle then there isn't a PG_FUNCTION_INFO_V1 marker, which maybe is the problem. regards, tom lane
On Mon, May 16, 2011 at 7:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 16, 2011 at 3:41 AM, Nick Raj <nickrajjain@gmail.com> wrote:>> "How to get arguments toastable??" and even my table pg_class.reltoastrelidIt could be if the type is not marked toastable (ie, has storage class
>> entry is zero.
> It's pretty hard to guess what's going wrong here from the information
> you've provided. But reltoastid should not be 0 if you're using a
> variable-length data type.
PLAIN, which I think is the default even for varlena types).
But in any case I suspect that 90% of the problem here is an incorrect
declaration of the *function* not the type. We haven't seen the C
function declaration, nor the SQL CREATE FUNCTION command, but if it's
going through fmgr_oldstyle then there isn't a PG_FUNCTION_INFO_V1
marker, which maybe is the problem.
Thanks for your replies
Tom, you are correct. I missed PG_FUNCTION_INFO_V1 marker. After adding this marker, my code works fine.
Thanks a lot.
Tom, you are correct. I missed PG_FUNCTION_INFO_V1 marker. After adding this marker, my code works fine.
Thanks a lot.
regards, tom lane