Anonymous Code Blocks as Lambdas?

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

Hello

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) $$
begin
raise notice 'TABLENAME IS %', table_name;
return;
end;
$$

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

comments?

Regards
Pavel

2009/10/26 Andrew Dunstan <andrew@dunslane.net>:

Andrew Dunstan <andrew@dunslane.net> writes:

David E. Wheeler wrote:

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.

It was discussed and rejected, at least for now. See earlier discussion.

A lambda facility would require being able to pass arguments and return
results, which we intentionally left out of DO to keep it simple. By
the time you add all that notation, it's far from clear that you
shouldn't just define a function.

Also, DO is (intended to be) optimized for execute-once behavior.
A lambda block inside a query shouldn't assume that. So it would not be
the same facility from either a syntax or an implementation standpoint.

regards, tom lane

On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:

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) $$
begin
raise notice 'TABLENAME IS %', table_name;
return;
end;
$$

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

How is this different from psql :variables? And why would a `DO`
feature be tied directly to psql?

Confused,

David

On Oct 26, 2009, at 1:21 PM, Tom Lane wrote:

A lambda facility would require being able to pass arguments and
return
results, which we intentionally left out of DO to keep it simple. By
the time you add all that notation, it's far from clear that you
shouldn't just define a function.

Well sometimes I want to do something like that as an expression,
rather than having to write a separate statement that declares a
function.

Also, DO is (intended to be) optimized for execute-once behavior.
A lambda block inside a query shouldn't assume that. So it would
not be
the same facility from either a syntax or an implementation
standpoint.

Perhaps lambda isn't the proper term.

Best,

David

2009/10/26 David E. Wheeler <david@kineticode.com>:

On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:

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) $$
begin
 raise notice 'TABLENAME IS %', table_name;
 return;
end;
$$

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

How is this different from psql :variables?

is is psql variables.

And why would a `DO` feature be

tied directly to psql?

it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.

On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:

it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.

I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish it was an expression!).

I don't think it's a good idea to tie SQL syntax to a feature of a
client, though.

Best,

David

David E. Wheeler wrote:

On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:

it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.

I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish it was an expression!).

I don't think it's a good idea to tie SQL syntax to a feature of a
client, though.

Me either.

I think we need to take this more slowly. Frankly, I think we have most
of what we really wanted already, and I suspect anything else is
probably not worth the code complexity involved. The original motivation
as I understood it was to enable people to embed a piece of pl/foo in a
script with minimal syntactic overhead, and I think that's been achieved.

cheers

andrew

2009/10/26 David E. Wheeler <david@kineticode.com>:

On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:

it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.

I see, because `DO` is a statement, not an expression. Thus arguments don't
really make much sense (I wish it was an expression!).

uff. How you would to write scripts? How you would to join client side
and server side? What I know, statements in PostgreSQL are
parametrised - INSERT, SELECT and others.

I don't think it's a good idea to tie SQL syntax to a feature of a client,
though.

DO should have any syntax. Other than I wrote. It isn't important in
this moment. Do without parametrsation has not full power. It is like
EXECUTE without USING clause. Sure. You can live without it, but the
live with it is much more confortable. So now we have isolated PL
fragment without any outer inputs.

Regards

Pavel

Pavel Stehule wrote:

2009/10/26 David E. Wheeler <david@kineticode.com>:

On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:

it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.

I see, because `DO` is a statement, not an expression. Thus arguments don't
really make much sense (I wish it was an expression!).

uff. How you would to write scripts? How you would to join client side
and server side? What I know, statements in PostgreSQL are
parametrised - INSERT, SELECT and others.

They are not arbitrarily parameterized at all. Just try using a
parameter for a table name. And not all statements accept parameters.

You are making a quite false comparison here.

I don't think it's a good idea to tie SQL syntax to a feature of a client,
though.

DO should have any syntax. Other than I wrote. It isn't important in
this moment. Do without parametrsation has not full power. It is like
EXECUTE without USING clause. Sure. You can live without it, but the
live with it is much more confortable.

There is no proof at all of this. We have not even released this feature
into the field and already you are declaring it inadequate. That
declaration is at best premature.

cheers

andrew