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@xxxxxxxxx> wrote:
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
