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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
