From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Hannu Krosing <hannu(at)krosing(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: multiple CREATE FUNCTION AS items for PLs |
Date: | 2012-12-17 21:47:16 |
Message-ID: | CAFj8pRA1vfB7Vk9jjRS+tUOnXLUn0E8-n=HzHpmk43hV+kxpJQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/12/17 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On 12/16/12 1:20 PM, Hannu Krosing wrote:
>> I was going to suggest some special function name to be pulled out of code
>> passed to CREATE FUNCTION in line with
>>
>> CREATE FUNCTION foo(a,b,c) AS $$
>> import x
>> from __future__ import nex_cool_feature
>>
>> def helper_function(x):
>> ...
>>
>> def __pg_main__(a,b,c):
>> defined function body here
>>
>> $$;
>>
>> so that the whole text gets compiled into module at first call and the
>> __pg_main__ will
>> be the function that gets called as foo(a,b,c) from postgresql
>>
>> but this would not be backwards compatible, at least not in any obvious way.
>
> 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')
>
> But this is also a lot more typing, so the two-part AS solution still
> has some appeal if you just want an import.
>
two-part AS is not intuitive and it is looking really obscure
Regards
Pavel
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-12-17 22:35:43 | Re: Error restoring from a base backup taken from standby |
Previous Message | Simon Riggs | 2012-12-17 21:42:54 | Re: Enabling Checksums |