Skip site navigation (1) Skip section navigation (2)

Re: Anonymous Code Blocks as Lambdas?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Anonymous Code Blocks as Lambdas?
Date: 2009-10-26 20:16:25
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers

I have a idea about migration of outer (psql) variables, and custom
shell variables.

some like:

psql --allow_custom_variables --table_name=mytable

inside psql we should to use :table_name variable with  "mytable" as content.

then we can use syntax

do (table_name varchar) $$
  raise notice 'TABLENAME IS %', table_name;

so with this mechanism we can to simply parametrise plpgsql "do"
scripts from outer environment.



2009/10/26 Andrew Dunstan <andrew(at)dunslane(dot)net>:
> David E. Wheeler wrote:
>> Howdy,
>> Very excited about the new `DO` command in 8.5a2. I read through the patch
>> review thread and found that, like me, Dim had expected it to behave more
>> like a lambda than a simple command. And from Tom's comments, it looks like
>> it was committed in such a way to make such extensions possible (passing
>> arguments, returning values (maybe even sets?).
>> So I was wondering if anyone has thought about adding such functionality,
>> and if so, what it might look like?
>> If the answer is "no, because we want to see what cow paths develop in
>> 8.5," that's fine with me. I'll just be chasing cows. :-)
> It was discussed and rejected, at least for now. See earlier discussion.
> cheers
> andrew
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-10-26 20:21:05
Subject: Re: Anonymous Code Blocks as Lambdas?
Previous:From: Peter EisentrautDate: 2009-10-26 20:09:34
Subject: Re: [ANNOUNCE] PostgreSQL 8.5alpha2 Now Available

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group