May you have the link to 'DO'-discussion to take a look on it? I was trying to google for something like that, but word 'DO' is too generic to bring useful results :(
In my particular case I'm more interested in an easy way to create complex SELECTs that require usage of variables in the one-time through-away scripts (some-time during experiments for implementation of functions, to see immediate results of the intermediate code). The easiest way would be MsSQL-like when declaring a variable outside of SP actually makes it visible globally in current session. In such case I do not need 'DO' at all and this is simple. Probably PostgreSQL has another way to make that thing simple. On Fri, Aug 12, 2016 at 1:19 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Mon, Aug 8, 2016 at 7:25 PM, Xtra Coder <xtraco...@gmail.com> 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 >
