Re: multiple CREATE FUNCTION AS items for PLs
От | Hannu Krosing |
---|---|
Тема | Re: multiple CREATE FUNCTION AS items for PLs |
Дата | |
Msg-id | 50CE1106.8020802@krosing.net обсуждение исходный текст |
Ответ на | Re: multiple CREATE FUNCTION AS items for PLs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: multiple CREATE FUNCTION AS items for PLs
Re: multiple CREATE FUNCTION AS items for PLs |
Список | pgsql-hackers |
On 12/16/2012 07:03 PM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> When you do >> CREATE FUNCTION foo(...) ... LANGUAGE plpythonu >> AS $$ >> source code here >> $$; >> it internally creates a "source file" that contains >> --- >> def __plpython_procedure_foo_12345(): >> source code here >> --- >> It would be useful to be able to do something like this instead: >> --- >> some code here >> def __plpython_procedure_foo_12345(): >> some more code here >> --- >> This would especially be useful for placing imports into the first part. > Sure, but wouldn't it be cleaner to do that via some language-specific > syntax inside the function string? I'm imagining some syntax like > > CREATE FUNCTION ... AS $$ > global[ some definitions here ] > function code here > $$; > > where the PL would be responsible for pulling off the "global" chunk > and structuring what it outputs accordingly. 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. ------------------- Hanniu >> CREATE FUNCTION already supports multiple AS items. Currently, multiple >> AS items are rejected for all languages but C. I'd imagine lifting that >> restriction and leaving it up to the validator to check it. Then any >> language can accept two AS items if it wants and paste them together in >> whichever way it needs. (The probin/prosrc naming will then become more >> obsolete, but it's perhaps not worth changing anything about that.) > I think doing it this way is a bad idea, mainly because (1) it won't > scale to more than two items (at least not without great rearrangement > of pg_proc) and (2) having two otherwise-unlabeled AS items isn't at all > understandable or readable. For instance, which of the two is the > global part, and why? The fact that C functions do it like that is a > legacy syntax we're stuck with, not a good model to copy for other > languages. > > regards, tom lane > >
В списке pgsql-hackers по дате отправления: