Re: 2 line patch to allow plpythonu functions to return void ...

On Feb 25, 2006, at 12:10 PM, Tom Lane wrote:

> James Robinson <jlrobins(at)socialserve(dot)com> writes:
>> Shamelessly cloned from the parallel code in pltcl, an exception for
>> void in denying pseudotypes being returned. Pl/tcl didn't reference
>> VOIDOID anywhere else, so ... .
>
> This sort of thing normally requires more thought than just removing
> the safety check. What happens when the python code does/doesn't
> return
> a value, in both cases (declared return type void or not)?
>
> regards, tom lane

Yes of course.

Here's some permutations of declared void functions explictly
returning a value or not, with the closest thing to void in Python
being None [ which is currently mapped to SQL NULL ] ...

create or replace function void_ret_notvoid() returns void as
$$
return 12
$$ language plpythonu;

-- return value '' comes decorated with oid 2278, which seems to be
VOIDOID. The 12 integer gets discarded. Ugly, yes.

create or replace function void_ret_none() returns void as
$$
return None
$$ language plpythonu;

-- Once again, returned oid to client is 2278, and likewise for the
subsequent one....

select void_ret_none() is null;

create or replace function void_ret_falloff_none() returns void as
$$
x = 12 + 4
$$ language plpythonu;

-- This one returns oid 23, with value NULL.

create or replace function notvoid_ret_none() returns int as
$$
return None
$$ language plpythonu;

Now, the python language semantics are that if a function does not
explictly return a value, None is implictly returned:

jlrobins:~ jlrobins$ python
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def falloff():
... x = 12
...
>>> val = falloff()
>>> val is None
True

So there's a bit of a mismatch between Python and SQL semantics since
Python's None is already being used to represent NULL [ of whatever
datatype the pl function was described to return at the SQL level ]
in plpython.

The ugliest case above is certainly the first one -- function
declared to be void explicitly returning a not-None value. That
should probably cause an SQL-level error. Can't really test it a
function compile time, since Python variables are not typed, only
what they reference are.

The intent was to have to keep from having to declare a bogus return
type for a a procedure that returns no meaningful results at all --
such as one which does nothing but inserts or updates or what have you.

I suspect that all of the above functions returned VOIDOID decorating
the return result due to machinery higher-up than plpython -- the
postgres typing system itself, so those cases are probably silly
examples, other than showing that it doesn't immediately crash. Which
you probably would rather be shown a much higher confidence proof
that the system is still correct aside from not immediately going
down in flames.

I'll go back to lurking and reading -- is the plpgsql source the best
model for reading up on procedure language implementation? Thanks.

----
James Robinson
Socialserve.com