On Feb 25, 2006, at 12:10 PM, Tom Lane wrote:
James Robinson [EMAIL PROTECTED] 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
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
