On Sun, Aug 16, 2009 at 03:57:08PM +0300, Peter Eisentraut wrote:
> On 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote:
> > SQL is not Lisp. Simple is good. I didn't think Peter was really very
> > serious.
>
> 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. So making DO or whatever a top-level command that does not
> integrate with anything else would not really satisfy me.
Wow, I didn't think you were serious either!
One thing that would make my life easier would be easier one-off custom
aggregations, this would seem to be a nice stepping stone towards that.
For instance the following "agg" function would have similar semantics
to "fold", as found in functional languages.
SELECT agg(LAMBDA (text,text) $$ SELECT $1||coalesce($2,''); $$, '', s) FROM (VALUES ('aa'), ('bb'))
x(s);
I'd expect to get 'aabb' back if I've done something wrong/it's
not obvious. I.e. the first parameter is like the SFUNC in CREATE
AGGREGATE, the second parameter ('') is the INITCOND, and the third
param (s) is what you want to aggregate.
You've now got two type variables in play and hence you'd want some
better support of parametric polymorphism than PG currently makes
easy. The current AGGREGATE infrastructure seems to get away with it by
bundling this type knowledge into the aggregate itself.
Also, why isn't SQL the default language--plpgsql still needs to be
explicitly added doesn't it?
-- Sam http://samason.me.uk/
