Обсуждение: Anonymous Code Blocks as Lambdas?
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
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>: > > > 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 >
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. > Confused, > > David >
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 > Best, > > David >
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