Re: [HACKERS] Crash on SRF execution

[Itai Dor-On]

Thanks Tom.

Assuming the SRF had a parameter, would this be a correct approach
(considering the iterative model) to bail-out early?

if (SRF_IS_FIRSTCALL())
{
        int i;
        
        if (get_call_result_type(fcinfo, NULL, &funcctx->tuple_desc) !=
TYPEFUNC_COMPOSITE) 
        {
                ereport(ERROR,
                (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
                 errmsg("Check if sql function definition returns SETOF
record")));             
                return;
        }

        if (PG_ARGISNULL(0)) 
        {
                ereport(ERROR,
                (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
                 errmsg("Null value not allow for ...")));
                 return;
        }
                 
        if((i = PG_GETARG_INT32(0)) != 'WHATEVER') 
        {
                ereport(ERROR,
                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                 errmsg("Null value not allow for ...")));
                 return;
        }

-----Original Message-----
From: Tom Lane [mailto:t...@sss.pgh.pa.us] 
Sent: Sunday, March 15, 2015 5:50 PM
To: Itai
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Crash on SRF execution

Itai <it...@outlook.com> writes:
> I'm attempting to program a simple SRF function but it constantly crashes
(details and code below).
> Any idea why?

Looks like you're pallocing some stuff in the calling context (ie, a
short-lived context) during the first execution and expecting it to still be
there in later executions.  You'd need to allocate those data structures in
the multi_call_memory_ctx instead.

                        regards, tom lane



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers