Re: Any reasons for 'DO' statement not returning result?

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 <mmoncure(at)gmail(dot)com> wrote:

> On Mon, Aug 8, 2016 at 7:25 PM, Xtra Coder <xtracoder(at)gmail(dot)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
>