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

On Sun, Aug 14, 2016 at 12:13 PM, Xtra Coder <xtracoder(at)gmail(dot)com> wrote:

> Thanks, I'm aware about ability to create temp functions, but this is
> actually too much overhead - I mean unneeded boilerplate code, but it seems
> in current state it is "the least evil" which I have to use.
>
> I think 'what i need' is support for following
> - ability to switch session language from 'sql' to 'pl/pgsql'
> - in that mode - ability to declare session-scope variables, 'DO' is just
> not needed after that
> - SELECTs not targeted into a variable - are written to client output
> - (C) Merlin Moncure - "Ability to embed collection of statements in the
> database under a name and invoke those statements via CALL <name>, which
> does not automatically create a transaction and a snapshot (unlike
> functions/DO)"
>
> All this seems to be a huge change which will definitely not appear any
> time soon.
>

I am willing to bet that DO $$ $$; blocks are neither planned nor
parameterized. And the planner needs to know what is to be returned.

So anything you add to make DO work well with the planner will probably end
you right back at the same amount of overhead as a temporary function.

>
> On Sun, Aug 14, 2016 at 10:42 AM, Chris Travers <chris(dot)travers(at)gmail(dot)com>
> wrote:
>
>> If all you want is a temporary function, you *can* create it in the
>> pg_temp namespace though that seems hackish.
>>
>> Maybe a better solution would be to extend CREATE FUNCTION in a way that
>> allows you to CREATE TEMPORARY FUNCTION?
>>
>> ...
>>
>> --
>> Best Wishes,
>> Chris Travers
>>
>> Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
>> lock-in.
>> http://www.efficito.com/learn_more
>>
>
>

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more