Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.

Hitoshi Harada

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group