Skip site navigation (1) Skip section navigation (2)

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

From: James Robinson <jlrobins(at)socialserve(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: 2 line patch to allow plpythonu functions to return void ...
Date: 2006-02-25 18:47:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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

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

In response to

pgsql-patches by date

Next:From: Neil ConwayDate: 2006-02-26 03:00:58
Subject: TID: <> operator
Previous:From: Harald Armin MassaDate: 2006-02-25 17:57:32
Subject: Re: 2 line patch to allow plpythonu functions to return void ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group