Re: WIP patch: convert SQL-language functions to return tuplestores
От | Tom Lane |
---|---|
Тема | Re: WIP patch: convert SQL-language functions to return tuplestores |
Дата | |
Msg-id | 13666.1225289240@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP patch: convert SQL-language functions to return tuplestores (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: WIP patch: convert SQL-language functions to return tuplestores
|
Список | pgsql-hackers |
Dimitri Fontaine <dfontaine@hi-media.com> writes: > Done this way, the user could also choose for the function to be lazy or to > use a tuplestore whatever the language in which it's written. The odds of this ever happening for any of the PLs are not distinguishable from zero. It might be nice to have, but the amount of work involved would be incredibly out of proportion to the benefits --- even assuming that it's technically possible at all, which I rather doubt for the PLs that depend on language interpreters that aren't under our control. So the fact that it's possible for SQL-language functions is an idiosyncrasy of that language, not something we should cram into the general CREATE FUNCTION syntax in the vain hope that having syntax might cause an implementation to appear someday. Therefore, if we were going to expose a knob to the user to control this behavior, I'd be inclined to make it a part of the language-specific syntax of SQL function bodies. We could take a hint from the (underdocumented) #option syntax in plpgsql, something like CREATE FUNCTION foo(...) RETURNS SETOF something AS $$ #option lazy SELECT ... $$ LANGUAGE SQL; Mind you, I'm not exactly *for* this, because I think it will result in making functions.c a whole lot more complex and hard to maintain than it needs to be, in exchange for a behavior that I don't believe is especially useful in most cases, and can easily be worked around when it is useful. But if people are going to be sticky about the point, something like this might be a workable compromise. regards, tom lane
В списке pgsql-hackers по дате отправления: