[HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread David E. Wheeler

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. :-)


Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread David E. Wheeler

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. :-)


Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread Andrew Dunstan



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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread Pavel Stehule
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 and...@dunslane.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@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread Tom Lane
Andrew Dunstan and...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread David E. Wheeler

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread David E. Wheeler

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread Pavel Stehule
2009/10/26 David E. Wheeler da...@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.

 Confused,

 David


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread David E. Wheeler

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread Andrew Dunstan



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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread Pavel Stehule
2009/10/26 David E. Wheeler da...@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
 Best,

 David


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Anonymous Code Blocks as Lambdas?

2009-10-26 Thread Andrew Dunstan



Pavel Stehule wrote:

2009/10/26 David E. Wheeler da...@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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers