Thread: Null handling and plpython

I'm reviewing the plpython data type handling patch from the commit fest.  I 
have not dealt much with the plpython code before, and I'm a bit puzzled by 
its elaborately silly handling of null values.  A representative example (for 
the current code):
        if (tupdesc->attrs[atti]->attisdropped)        {            modvalues[i] = (Datum) 0;            modnulls[i] =
'n';       }        else if (plval != Py_None)        {            plstr = PyObject_Str(plval);            if (!plstr)
             PLy_elog(ERROR, "could not compute string representation of Python 
 
object, while modifying trigger row");            src = PyString_AsString(plstr);
            modvalues[i] =                InputFunctionCall(&proc->result.out.r.atts[atti].typfunc,
            src,                                proc->result.out.r.atts[atti].typioparam,
  tupdesc->attrs[atti]->atttypmod);            modnulls[i] = ' ';
 
            Py_DECREF(plstr);            plstr = NULL;        }        else /* FUN STARTS HERE */        {
modvalues[i]=                InputFunctionCall(&proc->result.out.r.atts[atti].typfunc,
NULL,                               proc->result.out.r.atts[atti].typioparam,
tupdesc->attrs[atti]->atttypmod);           modnulls[i] = 'n';        }
 
        Py_DECREF(plval);        plval = NULL;    }
    rtup = SPI_modifytuple(tdata->tg_relation, otup, natts,                           modattrs, modvalues, modnulls);

First of all, SPI_modifytuple (which wraps around heap_modify_tuple) appears 
to ignore the values when a slot is marked to be null.

And then, what is the supposed semantics of calling a nonstrict input function 
with NULL as the cstring value?  InputFunctionCall() requires that the return 
value is null if and only if the input cstring was NULL, "but we'll call the 
input function anyway".  Couldn't the call to InputFunctionCall() be scrapped 
altogether in the above case?

Peter Eisentraut <peter_e@gmx.net> writes:
> And then, what is the supposed semantics of calling a nonstrict input
> function with NULL as the cstring value?  InputFunctionCall() requires
> that the return value is null if and only if the input cstring was
> NULL, "but we'll call the input function anyway".  Couldn't the call
> to InputFunctionCall() be scrapped altogether in the above case?

No.  The point of this is to allow domain_in() to apply domain
constraint checks that might or might not throw error on null values.
I'm not sure whether the code you quote is getting this right in
all the branches, but the last case isn't useless.
        regards, tom lane