Re: WIP patch: convert SQL-language functions to return tuplestores - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: WIP patch: convert SQL-language functions to return tuplestores
Date
Msg-id 200810291551.28666.dfontaine@hi-media.com
Whole thread Raw
In response to Re: WIP patch: convert SQL-language functions to return tuplestores  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP patch: convert SQL-language functions to return tuplestores
List pgsql-hackers
Le mercredi 29 octobre 2008, Tom Lane a écrit :
> 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.

Ok, that confirms that lazy evaluation and call-per-value are distinct things,
for once, and that what you where after was not an easy syntax bit. :)

> 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.

How would we support the option for SQL functions?

> 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.

From what I understand, the lazy evaluation of functions is not seen as easy
to be worked around by people asking for it.

> But if people are going to be sticky about the
> point, something like this might be a workable compromise.

What's against PLpgSQL implementing a YIELD statement? Wouldn't it be simpler
to integrate for both hackers and users?

This would maybe even allow to have a new API in the executor for this, and
each PL would be free to add support for it when best suits them. Maybe
that's exactly what you're calling "a whole lot more complex and hard to
maintain than it needs to be", though.

Regards,
--
dim

pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: htup and bufpage API clean up
Next
From: Andrew Dunstan
Date:
Subject: WIP parallel restore patch