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?
