On Fri, Dec 28, 2012 at 12:24 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2012/12/28 Peter Eisentraut <pete...@gmx.net>: >> On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote: >>> Yes, this would be a good solution for some applications, but the only >>> way I can think of to manage the compatibility issue is to invent some >>> function attribute system like >>> >>> CREATE FUNCTION ... OPTIONS (call_convention 'xyz') >> >> An alternative that has some amount of precedent in the Python world >> would be to use comment pragmas, like this: >> >> CREATE FUNCTION foo(a,b,c) AS $$ >> # plpython: module >> import x >> from __future__ import nex_cool_feature >> >> def helper_function(x): >> ... >> >> def __pg_main__(a,b,c): >> defined function body here >> >> $$; >> >> The source code parser would look for this string on, say, the first two >> lines, and then decide which way to process the source text. >> >> This way we could get this done fairly easily without any new >> infrastructure outside the language handler. > > this concept looks like more stronger and cleaner > > +1 > > I thing so same idea is used in PL/v8 >
What part of PL/v8 do you think is same?? It parses the body as other PLs do and nothing special. plv8 also wanted this notion of "function setting" before introducing find_function(), which natively loads other JS functions that are defined via CREATE FUNCTION. Of course it is not optimal, but it turned out it is not terribly slow. Maybe it depends on language runtime. So for now, PL/v8 is managing to do it and happy with the existing mechanism. It could be improved somehow, but I don't want it to be complicated than now in order to improve small stuff. Thanks, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
