Re: multiple CREATE FUNCTION AS items for PLs

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Hannu Krosing <hannu(at)krosing(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: multiple CREATE FUNCTION AS items for PLs
Date: 2013-01-03 06:13:47
Message-ID: CAP7Qgm=fjv_k3SR-R8xy+CfPakyrtOoFqCwwL4LDr==9tVtp2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 28, 2012 at 12:24 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2012/12/28 Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-01-03 07:55:03 Re: proposal: ANSI SQL 2011 syntax for named parameters
Previous Message Andrew Dunstan 2013-01-03 04:58:10 Re: Problematic dependency in plpython Makefile [Windows]