Tom Lane napsal(a):
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Well, I don't know if we really need to call it "lambda", but I fully
>> expect to be able to use these "ad hoc functions" as part of other
>> expressions.
>
> Why would you expect that? To be used in an expression, you'd also need
> decoration to tell the function argument types, result type, volatility
> properties, etc etc (your proposed lambda notation is far too
> simplistic). I think you're moving the goalposts to a point where we'd
> need ANOTHER, simpler, mechanism to accomplish the original intent.
> And frankly, all of the user demand I've heard is for the latter not
> the former. By the time you get into specifying function properties
> you might as well just create a function.
>
I agree with Tom here, doing it the way Andrew and Tom agreed on will be
*way* easier and will give us most of the benefit (as Heikki said "90%
of the usability with 10% of the trouble").
I volunteer to do this feature too.
The implementation as I see it would create function in pg_temp
namespace, call it and then drop it. Any other implementation would imho
mean rewriting procedure language api.
I am unsure if we should try to make the name of the function unique,
since it should not collide with anything if we allow just one statement
at a time (transactional DDL wins again), or am I mistaken here ?
Also do we want the LANGUAGE option to be at start or at the end or
anywhere (like it's in CREATE FUNCTION). The reason I am asking this is
that if we let user to put it on both sides then the LANGUAGE keyword
can't be optional (what Dimitri Fontaine wanted).
And last thing I am wondering is if we want to allow DO to return rows
(probably by creating the function with SETOF record as return type) ?
I am guessing not here since if user wants to run something often then
he should crate a function.
Otherwise this should be quite straightforward (I have working code
already).
--
Regards
Petr Jelinek (PJMODOS)
