On Mon, Aug 8, 2016 at 7:25 PM, Xtra Coder <xtracoder@xxxxxxxxx> wrote: > Hi, > > I'm just curious about the reasons of the design of 'DO' statement so that > it is not able to return result of the SELECT in its body. > > References: > https://www.postgresql.org/docs/current/static/sql-do.html > > http://stackoverflow.com/questions/14652477/how-to-perform-a-select-query-in-a-do-block > > With some former experience with MsSQL server, where 'complex' script is > executed easily and straightforward without any 'wrapping', like this > dummy-one ... > > DECLARE @a int; > DECLARE @b int; > ... > select @a + @b as "a+b" > > ... every time I need to execute some one-time-through-away complex code in > PostgreSQL which returns rowset I'm disappointed - this has to be wrapped > into normal 'temp' function which I have to delete all the time in current > session, thus making an anonymous 'DO' statement use-less in 95% of my > use-cases. > > So ... may someone know good reasons for such inconvenient design of 'DO' > statement? IIRC past discussion concluded DO statements should be allowed to return values. What you (or at least I-) really want though is stored procedures. To me, this means the following: *) Ability to embed collection of statements in the database under a name *) Ability to invoke those statements via CALL <name>, which does not automatically create a transaction and a snapshot (unlike functions/DO) I used to think that we needed to pick a procedural language (for example, pl/pgsql) to leverage the various programming niceties of the database (such as variables and flow control). Today I'm thinking it ought to be vanilla SQL for starters, with some judicious SQL extensions to be hashed out later. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
