Re: multiple CREATE FUNCTION AS items for PLs

On 12/16/2012 10:23 PM, Peter Eisentraut wrote:
> On Sun, 2012-12-16 at 19:13 +0100, Hannu Krosing wrote:
>> As an idea seems quite good, but maybe the "run once" part could use
>> its
>> own keyword in the future, something like PREPARE or REQUIRE?
> Well, either we do it in a language independent way, in which case this
> would be too prescriptive, or we do it in a Python-specific way (less
> likely), but "prepare" or "require" are not Python concepts.
The proposed keywords names are meant to be language-independant
and to signify the the part that is meant for initialisation or 
requirements.

The multiple AS $$...$$ sections have to mean something to be useful at all.

My final choce of WITH seem to both fit with run-one/required/init meaning
and is already a keyword.

But I'd ended preferring much more the approach of putting the whole
function module in functions source code and returning as the plpython
function the item matching of the defined function which can be a function
or any other callable.

The main problem is staying backwards compatible with existing 
implementation.

>> WHile at it, why not also fix the functions to be real function
>> _with_ _real_ _arguments_ , not arguments-passed-in-as-globals
>>
>> and at least we could call this function with its real name inside its
>> own module
>> (stored global namespace) so we could easily do recursion
>>
>> CREATE FUNCTION factorial(n bigint) returns bigint LANGUAGE plpythonu
>> AS $$
>>       if n==0: return 1
>>       return factorial(n-1) * n
>> $$;
>>
> These are also good things to fix, but are they related?  Could they not
> be fixed independently?
They could, but fixing these together will probably result in a cleaner 
design :)

even with your original multiple-code-strings design you end up 
manipulating
function-global namespaces (which seem really close to modules) to put the
first $$...$$ there as run-once, pre-def code.

using functions real name (instead of _plpython_<funcname>_<oid>) in its 
module
namespace is an one-line fix but to be really useful the mess with 
arguments-as-globals
needs to be rectified.

if we move to the function-code-as module approach we will no longer need
to munge code (add def .... before code and then \t at the beginning of 
each line)
which makes everything much cleaner.

The main thing to solve is different model for passing function 
arguments at call time.

---------------
Hannu