Re: WIP patch: convert SQL-language functions to return tuplestores

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores
Date: 2008-10-29 14:51:26
Message-ID: 200810291551.28666.dfontaine@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-10-29 14:52:28 WIP parallel restore patch
Previous Message Zdenek Kotala 2008-10-29 14:40:58 Re: htup and bufpage API clean up