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

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to